Nick Coghlan added the comment:
As part of this, I finally reviewed Jim's proposed alternate implementations
for the helper functions. Katie's patch used my version while I figured out the
differences in behaviour :)
The key difference between them relates to the following different approaches
to handling unknown types in __eq__:
@functools.total_ordering
class TotallyOrderedEqualsReturnsFalse:
def __init__(self, value):
self._value = value
def __eq__(self, other):
return isinstance(other, Weird) and self._value == other._value
def __lt__(self, other):
if not isinstance(other, Weird): return NotImplemented
return self._value < other._value
@functools.total_ordering
class TotallyOrderedEqualsReturnsNotImplemented:
def __init__(self, value):
self._value = value
def __eq__(self, other):
if not isinstance(other, Weird): return NotImplemented
return self._value == other._value
def __lt__(self, other):
if not isinstance(other, Weird): return NotImplemented
return self._value < other._value
Formally, the version which returns False directly is incorrect - it should be
returning NotImplemented, and letting Python take of converting two results of
NotImplemented to an equality comparison result of False.
In practice, lots of types are written that way, so we need to preserve the
current behaviour of not checking the equality operations if the ordered
comparison isn't implemented, or we will inadvertently end up making "<=" or
">=" return an answer instead of raising TypeError.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
