[Python-Dev] The path module PEP

Thu Jan 26 00:42:13 CET 2006

[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