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@colorstudy.com / http://blog.ianbicking.org