On Mon, Jul 8, 2013 at 3:30 AM, Nick Coghlan wrote:

> The key difference between them relates to the following different approaches to handling unknown types in __eq__:

> @functools.total_ordering
> class TotallyOrderedEqualsReturnsFalse:
...
>    def __eq__(self, other):
>        return isinstance(other, Weird) and self._value == other._value

> @functools.total_ordering
> class TotallyOrderedEqualsReturnsNotImplemented:
...
>    def __eq__(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.

I had not considered this.  I'm not sure exactly where to improve the
docs, but I think it would be helpful to use a docstring (or at least
comments) on the test cases, so that at least someone looking at the
exact test cases will understand the subtlety.

> 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.

I had viewed that as a feature; for types where only some values will
have a useful answer, I had thought it better to still return that
answer for the values that do have one.  I freely acknowledge that
others may disagree, and if you say the issue was already settled,
then that also matters.

-jJ