path module
Ian Bicking
ianb at colorstudy.com
Tue Jul 8 05:15:34 EDT 2003
On Tue, 2003-07-08 at 03:17, Just wrote:
> I would greatly appreaciate such a module in the std library, but while
> Jason's module has some very cool features, to my taste it goes a bit
> too far with overloading operators. I really don't like overloading a/b
> to mean os.path.join(a, b) and I don't think the default iterator should
> do a listdir (although list(mypath) is indeed cute). If it were toned
> down a bit in this area I think we may be able to make a good case for
> including it in the std library.
I've never wanted to iterate over a string, and find that an annoying
feature in Python (I'd *much* rather get an exception), so covering up
the previous string behavior doesn't seem a big deal to me. But I can
see why iterating over a path may be a little too magic. But paths are
also containers (at least if they point to a directory), so iterating
over them seems only natural. I could see something like mypath.dir()
being reasonable alternative (mypath.list() also, but that looks funny
to me because "list" is special to my eye).
I do like the /, though. mypath.joinpath(filename) is rather
long-winded (since he wisely avoids reusing the join method). / has no
meaning for strings, so it's not really overloading the operator, merely
adding it in a specific context. Several operators are reused for
different meanings, % in particular comes to mind, this doesn't seem
that bad. I like the way it looks and feels. It feels better to me
than using + for string concatenation ;) -- maybe because division is
not all that common an operation anyway.
Ian
More information about the Python-list
mailing list