Eric V. Smith wrote:
>That makes things worse. Now the comparison is always true in a boolean
>context. And presumably you'd want __ne__ to also return >NotImplemented,
>so then both __eq__ and __ne__ would be true, since >bool(NotImplemented)
>is True.
Eric V Smith wrote:
7/25/2019 6:00 AM, Eric V. Smith wrote:
>I might have to take that back. I hadn't factored in what the == and !=
>machinery does, beyond calling __eq__ or __ne__.
Based on the behavior in this example class, it looks like this would still
function appropriately, despite the value of bool(NotImplemented):
>>>class A:
def __eq__(self, other):
return NotImplemented
>>>a = A()
>>>b = A()
>>> a == b
False
>>> a != b
True
As you said, I believe it has to do with the underlying behavior of __eq__ and
__ne__. However, this does somewhat lead to the same surface level issue of a
False ultimately being returned. The NotImplemented makes the intention a bit
more obvious if someone were to look at the __eq__ method for dict.values(),
but otherwise it might still be the same issue. I'm somewhat curious as to why
`a == b` doesn't directly return NotImplemented instead of False. Perhaps the
underlying behavior makes it a pain to return anything other than True, False,
or None (that's purely speculation on my part, I haven't looked further into
it).
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/HTFXIN7L2UBEJ26AY2BTF5FEYA7MVUEX/
