path module

Ian Bicking ianb at
Tue Jul 8 11:15:34 CEST 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.


More information about the Python-list mailing list