path module

[Ian Bicking]

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

> I find overloading / unneccesary, since it's not like you'll have to
> write
> 
>   a.join(b).join(c).join(d)
> 
> 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
string).

> Btw. long ago (2001, before Jason's path module) I posted a balloon to
> python-dev about this subject:
> http://mail.python.org/pipermail/python-dev/2001-August/016663.html
> 
> 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 ;).

  Ian