PRE-PEP: new Path class

[Just]

[Mike C. Fletcher]
> > That said, I don't mind making path it's own base-class, I just *really*
> > want to be able to pass them to path-unaware code without extra coercian
> > (otherwise switching a module to *producing* paths instead of raw
> > strings will cause the *clients* of that module to break, which is a
> > serious problem for rapid adoption).

[John Roth]
> That's an excellent point, but it begs the question of which
> string class it should subclass. Unless it's got some way of
> changing its base class depending on the system it's running
> on. That, in turn, probably violates the Principle of Least
> Astonishment.

That's in fact exactly what Jason Orendorff's path module does. But it's 
buggy due to os.path.supports_unicode_filenames being buggy.

It would be interesting to figure out to what extent non-string (and 
non-unicode) path objects can or can't be made to work for existing 
string-accepting code. I would very much prefer a path _not_ to inherit 
from str or unicode, but Mike's point is an important one. What is 
missing in Python to allow non-string objects to act like (unicode) 
strings?

Just