Jim Jewett added the comment: 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 ---------- _______________________________________ 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
