path module

[Just]

In article <mailman.1059144006.6426.python-list at python.org>,
 holger krekel <pyth at devel.trillke.net> wrote:

> Jason Orendorff wrote:
> > I wrote the 'path' module at:
> >     http://www.jorendorff.com/articles/python/path
> > 
> > There was some discussion on it here:
> >     http://groups.google.com/groups?th=42ab4db337b60ce3
> > 
> > Just a few comments:
> > 
> > Ian and Holger wondered why 'path' should subclass 'str'.  It's because
> > a path is a string.  Benefit: you can pass 'path' objects to functions
> > that expect strings (like functions in 'win32file').  I find this
> > really useful in practice.
> 
> IMO you'll almost never use the following string-methods on a 'Path' object:
> 
>     capitalize center count decode encode
>     expandtabs find index isalnum isalpha isdigit
>     islower isspace istitle isupper 
>     ljust lstrip rjust splitlines startswith
>     swapcase title translate zfill
> 
> and so these methods pollute a Path object's name-space quite a bit. 
> Also 'join', '__contains__', startswith etc. produce some ambigouity.
> 
> I think it's convenient enough to use "str(path)" if passing a 'path' 
> instance as a string somewhere.

If the path object has a __str__ method, apparently it should work 
without explicit conversion. However, this seems to fail for me on OSX, 
where an attempt is made to convert to unicode. Providing a __unicode__ 
method doesn't help. But then again, I think we'd be fine if we add the 
most used path-taking functions to the path object as methods. I can 
even see adding some win-specific methods to it.

Just