[Python-Dev] Unipath package

[Mike Orr]

On 1/28/07, Steven Bethard <steven.bethard at gmail.com> wrote:
> On 1/28/07, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> > Mike Orr wrote:
> > > I finally finished my path package (Unipath) and put it in the Cheeseshop.
> > > http://sluggo.scrapping.cc/python/unipath/
> > >
> > Hello Mike,
> >
> > Looking through the docs it looks like a great package. However, didn't
> > Guido (on this list anyway) rule that he wouldn't accept a solution
> > which subclassed a string type?
>
> To be easily useful as a third-party module, it needs to subclass
> str/unicode so you can pass it directly to something like open().
> That inheritance could be dropped if the module was included in the
> stdlib, as long as the inclusion was also accompanied by appropriate
> modifications to open()/file() to allow Path objects.

Character slicing and some other string methods are also immensely
useful.  Subclassing string allows you to get all of them at once,
rather than leaving out the one that was not foreseen to be needed.  I
was formerly a fan of the tuple-component approach but somebody said
it splits the path too early, makes too many platform-specific
assumptions or something like that.  In practice, you really do want a
path compatible with string so you can pass it to any function (stdlib
or third-party) that accepts a string path, without getting into cases
where you have to cast it (str()).  There's also the string/unicode
problem in Python 2.x: if you call str() on a string containing
non-ASCII characters, you get an exception, and it's not always
possible to guarantee the string you got from some other code is safe.

If the BDFL does not accept a string-based path class, it will still
have a long happy life as a third-party library.

-- 
Mike Orr <sluggoster at gmail.com>