[Python-Dev] The path module PEP

[Ian Bicking]

Tony Meyer wrote:
>>Remove __div__ (Ian, Jason, Michael, Oleg)
>>
>>This is one of those where everyone (me too) says "I don't care either
>>way." If that is so, then I see no reason to change it unless someone
>>can show a scenario in which it hurts readability. Plus, a few people
>>have said that they like the shortcut.
>>
>>* http://mail.python.org/pipermail/python-list/2005-July/292251.html
>>* http://mail.python.org/pipermail/python-dev/2005-June/054496.html
>>* http://mail.python.org/pipermail/python-list/2005-July/291628.html
>>* http://mail.python.org/pipermail/python-list/2005-July/291621.html
> 
> 
> Well, if you include the much larger discussion on python-list,  
> people (including me) have said that removing __div__ is a good  
> idea.  If it's included in the PEP, please at least include a  
> justification and cover the problems with it.  The vast majority of  
> people (at least at the time) were either +0 or -0, not +1.  +0's are  
> not justification for including something.

If it were possible to use .join() for joining paths, I think I wouldn't 
mind so much.  But reusing a string method for something very different 
seems like a bad idea.  So we're left with .joinpath().  Still better 
than os.path.join() I guess, but only a little.  I guess that's why I'm 
+1 on /.

> Against it:
> 
>   * Zen: Beautiful is better than ugly. Explicit is better than  
> implicit. Readability counts. There should be one-- and preferably  
> only one --obvious way to do it.

I think / is pretty.  I think it reads well.  There's already some 
inevitable redundancy in this interface.  I use os.path.join so much 
that I know anything I use will feel readable quickly, but I also think 
I'll find / more appealing.

>   * Not every platform that Python supports has '/' as the path  
> separator.  Windows, a pretty major one, has '\'.  I have no idea  
> what various portable devices use, but there's a reasonable chance  
> it's not '/'.

I believe all platforms support /; at least Windows and Mac do, in 
addition to their native separators.  I assume any platform that 
supports filesystem access will support / in Python.

If anything, a good shortcut for .joinpath() will at least encourage 
people to use it, thus discouraging hardcoding of path separators.  I 
expect it would encourage portable paths.

Though Path('/foo') / '/bar' == Path('/bar'), which is *not* intuitive, 
though in the context of "join" it's not as surprising.  So that is a 
problem.  If / meant "under this path" then that could be a useful 
operator (in that I'd really like such an operator or method).  Either 
paths would be forced to be under the original path, or it would be an 
error if they somehow escaped.  Currently there's no quick-and-easy way 
to ensure this, except to join the paths, do abspath(), then confirm 
that the new path starts with the old path.

>   * It's being used to mean "join", which is the exact opposite  
> of /'s other meaning ("divide").
> 
>   * Python's not Perl.  We like using functions and not symbols.

A little too heavy on the truisms.  Python isn't the anti-Perl.

>>Renaming methods because of PEP 8 (Gustavo, Ian, Jason)
>>
>>I'm personally not keen on that. I like most of the names as they
>>are. abspath(), joinpath(), realpath() and splitall() looks so much
>>better than abs_path(), join_path(), real_path() and split_all() in my
>>eyes. If someone like the underscores I'll add it to Open Issues.
> 
> 
> +1 to following PEP 8.  These aren't built-ins, it's a library  
> module.  In addition to the PEP, underscores make it much easier to  
> read, especially for those for whom English is not their first language.

I don't find abs_path() much easier to read than abspath() -- neither is 
a full name.  absolute_path() perhaps, but that is somewhat redundant; 
absolute()...?  Eh.

Precedence in naming means something, and in this case all the names 
have existed for a very long time (as long as Python?)  PEP 8 encourages 
following naming precedence.  While I don't see a need to match every 
existing function with a method, to the degree they do match I see no 
reason why we shouldn't keep the names.  And I see reasons why the names 
shouldn't be changed.


-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org