ianb at colorstudy.com
Tue Jul 8 19:42:45 CEST 2003
On Tue, 2003-07-08 at 05:07, Just van Rossum wrote:
> > 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 +.
True... and as I think about it, a lot of the actually interesting
string methods wouldn't be performed on the entire path anyway. Things
like path.name.startswith('img'), or path.ext == 'jpg'. You could also
do things like override equals, so that two Windows paths would match
case-insensitively, and other things that would be bad to change in a
> 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.
And you could reuse the join method, which is better than joinpath (but
joinpath is better than overriding string's join, if you are subclassing
> 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.
You don't want to use open() anyway, that breaks the possibility of
alternate filesystems. There should be an open method, like
path.open('w'). Then a URL object (called maybe url?) would also have
an open method, that obviously would do a much different thing. (And
just as I'm thinking of a url class, things like .exists() would be
surprisingly useful, even though urllib doesn't expose these file-like
operations very directly)
The only other way is if a new magic method -- __open__ -- came into
being. That would be interesting (where "interesting" can be read
several ways ;).
More information about the Python-list