[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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
