just at xs4all.nl
Fri Jul 25 17:22:17 CEST 2003
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.
More information about the Python-list