Just van Rossum
just at xs4all.nl
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: path.py
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
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