[Python-Dev] The path module PEP

[Tony Meyer]

[Ian Bicking]
> 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 /.

Why does reusing a string method for something very different seem  
like a bad idea, but reusing a mathematical operator for something  
very different seem like a good idea?  Path's aren't strings, so join 
() seems the logical choice.  (There are also alternatives to  
"joinpath" if the name is the thing: add(), for example).

[Tony Meyer]
>> 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.

I suppose that the only beholder's eye that matters here is Guido's.   
(It still violates explicit/implicit and only-one-way.  Not rules, of  
course, but good guidelines).

>   There's already some inevitable redundancy in this interface.

That's hardly a reason to encourage *more*.  If anything, it's a  
reason to try for less, where possible.

>>   * 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.

This is not strictly true.  Using '/' can lead to strange results  
with Windows, where it gets interpreted as a flag instead.  It's not  
reliable, it's not the path separator that Windows users/developers  
understand, and it's not the correct (i.e. according to Microsoft)  
path separator.  If by Mac you mean OS X, then that's just another  
*nix based OS.  I'm pretty sure that pre OS X (which isn't supported  
any more anyway, right?) '/' was not, in fact, supported, and that  
":" was required.  I also believe it's important to remember that  
Windows and *nix descendants are not "all platforms".

> 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.

I'm not sure that I believe that the reason that people don't type  
"os.path.join('a', 'b')" is because they are too lazy to type it.   
However, I don't have any evidence either way, so it could be true.

[re: PEP8 following]
> 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.

PEP 8 encourages following naming precedence within a module, doesn't  
it?  Guido has said that he'd like to have the standard library  
tidied up, at least somewhat (e.g. StringIO.StringIO ->  
stringio.StringIO) for Python 3000.  It would make it less painful if  
new additions already followed the plan.

=Tony.Meyer