path module

Just van Rossum just at
Tue Jul 8 12:07:48 CEST 2003

Ian Bicking wrote:

> 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),

It's basically a side effect of having a __getitem__ that takes

> so covering
> up the previous string behavior doesn't seem a big deal to me. 

It's not just that, but iterating over a path could _also_ mean to
iterate over the path elements, so it's not obvious it should iterate
over the directory contents. Also, what if path points to a file?

> 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'd say path.listdir() is most natural.

> 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. 

It'll confuse the hell out of people who expect / to mean "divide" ;-)

> 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.

I tend to think that this whole discussion shows that _maybe_ it's not
such a good idea to subclass str/unicode after all. (Aside:
taught me about the existence of os.path.supports_unicode_filenames in
2.3, but at least on my platform (OSX) it has the wrong value. I opened
a bug, #767645.)

Some string methods are handy on paths, such as .endswith(), while
others are not, like .upper() or .splitlines(). Other string method
names or operators would make sense for paths, but -- as you say -- are
out of the question since their meaning would be quite different, eg.
.join() and +.

I find overloading / unneccesary, since it's not like you'll have to


but rather

  a.join(b, c, d)

which I don't think is all that bad.

Btw. long ago (2001, before Jason's path module) I posted a balloon to
python-dev about this subject:

There was hardly any response, and Guido said we wasn't too enthusiastic
about the idea, so we might have to work hard to pull this off ;-).

Also, with unicode, Guido's suggestion that any object that implements
__str__ can be used with open() seems to be no longer true. At least I
can't get it to work.


More information about the Python-list mailing list