[path-PEP] Path inherits from basestring again

[Michael Hoffman]

Reinhold Birkenfeld wrote:

> I'm in no way the last instance on this.
> For example, everyone with CVS access is free to change the files ;)

I don't have CVS write access :(, so I'll have to keep kibitzing for now.

> Honestly, I'm in constant fear that allowing too much and loading too much
> features won't increase the acceptance of python-dev <wink>

What do you mean by this? To me code like this:

if _base is str:
     def __eq__(self, other):
         return isinstance(other, Path) and _base.__eq__(self, other)
[...]
else:
     # Unicode has no rich compare methods
     def __cmp__(self, other):
         if isinstance(other, Path):
             return _base.__cmp__(self, other)
         return NotImplemented

is the feature that you do not need: the feature of not returning True. 
You don't need this feature, and I consider it to be harmful. It breaks 
duck-typing unnecessarily, and means that people who want to use some 
other path library, or just str/unicode as they do today cannot compare 
those paths against stdlib Paths.

We should retain the design principle of the original path.py that Path 
objects should be drop-in replacements for the str or unicode objects 
they replace, as much as possible. We cannot predict all the things 
people are doing with strings today, and attempting to do so can only 
lead to bugs.

In the current implementation, the only cases where a path object cannot 
be used as a drop-in replacement for a string are (a) some extension 
modules, and (b) code that tests the object class using type() instead 
of using isinstance(). I think these are unavoidable but other 
incompatibilities, like changing the semantics of comparisons or join() 
are avoidable.

I've started a Wiki page for design principles and discussion here:

http://wiki.python.org/moin/PathClass
-- 
Michael Hoffman