[Python-Dev] The path module PEP (original) (raw)

Tony Meyer t-meyer at ihug.co.nz
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

More information about the Python-Dev mailing list