[Python-Dev] Unipath package (original) (raw)

Mike Orr sluggoster at gmail.com
Sun Jan 28 19:43:07 CET 2007

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>

More information about the Python-Dev mailing list