Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #80909 > unrolled thread

What does this line of code mean?

Back to article view | Back to comp.lang.python

Contents

  What does this line of code mean? Abdul Abdul <abdul.sw84@gmail.com> - 2014-11-16 22:45 +0100
    Re: What does this line of code mean? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-16 23:07 +0100
    Re: What does this line of code mean? Rick Johnson <rantingrickjohnson@gmail.com> - 2014-11-19 19:42 -0800

#80909 — What does this line of code mean?

[Multipart message — attachments visible in raw view] — view raw

I just came across the following line of code:

outputfile = os.path.splitext(infile)[0] + ".jpg"

Can you kindly explain to me what those parts mean?

Thanks.

[toc] | [next] | [standalone]

#80921

Abdul Abdul wrote:

> I just came across the following line of code:
> 
> outputfile = os.path.splitext(infile)[0] + ".jpg"
> 
> Can you kindly explain to me what those parts mean?

RTFM: 
<https://docs.python.org/3/search.html?q=splitext&check_keywords=yes&area=default>

An Python IDE like PyDev will also display the docstring of the method when 
you position the pointer cursor over the symbol.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#81051

On Sunday, November 16, 2014 3:45:58 PM UTC-6, Abdul Abdul wrote:
> I just came across the following line of code:
> 
> outputfile = os.path.splitext(infile)[0] + ".jpg"
> 
> Can you kindly explain to me what those parts mean?

What that line of code "means" is:

  The author is far too dependent on authority (Python) and
  either lacks the *motivation* to improve the situation, or
  lacks the *skill* to improve the situation -- or both!

It is my strong opinion that path munging like the type
displayed here should be avoided when all possible. The
author is doing more work than he needs to do and he's doing
the work in an overly cryptic manner. Sure, any Python coder
worth his SALT can grok the code, but Python code like this
should never be celebrated, it should be excommunicated!

Instead of calling a function that splits a file-path, *THEN*
indexing the return value of the split to fetch a subsection
(YUCK!), *THEN* concatenating the fetched subsection with a
new extension (PUKE!)... he should have called one simple
*SELF-EXPLANATORY* method:
    
    os.path.substitute_extension(inPath, ".jpg")
    
But of course that method does not exists in *YOUR* Python!
No, you're forced to drink the cheap, "powdery tasting",
bitterly-under-sugared kool-aide that the os.path module has
demanded of you.

    "Oh Yeah!"
    
    Urm, 
    
    Oh *NO THANKS*!

To further aid in memory recall, the os.path module should
have many "get_*" and "substitute_*" methods, however, it
should have *ONLY* one "split" method which breaks a path
into *ALL* of it's atomic parts:

    drive, folder, filename, extension = os.path.split(path)

Of course the author also failed to use intuitive "self
documenting" names. "infile" suggest a file *object*, when
"inPath" and "outPath" are better suited to suggesting file
paths as *strings*.




  
  

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web