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
--
http://mail.python.org/mailman/listinfo/python-list
