Thanks for the good explanation.
My intention was to pass a custom method/function as a comparator
to an object. My misconception was, that __eq__ is equivalent to
the '==' operator, and could be passed as a first class function.
Apparently, that is not possible without wrapping the comparison
into another function/method.
Best regards,
Markus R.
On 05.08.2013 01:06, Chris Angelico wrote:
On Sun, Aug 4, 2013 at 11:35 PM, Markus Rother <pyt...@markusrother.de> wrote:
Hello,
The following behaviour seen in 3.2 seems very strange to me:
As expected:
() == []
False
However:
().__eq__([])
NotImplemented
[].__eq__(())
NotImplemented
You don't normally want to be calling dunder methods directly. The
reasoning behind this behaviour goes back to a few things, including a
way to handle "1 == Foo()" where Foo is a custom type that implements
__eq__; obviously the integer 1 won't know whether it's equal to a Foo
instance or not, so it has to defer to the second operand to get a
result. This deferral is done by returning NotImplemented, which is an
object, and so is true by default. I don't see any particular reason
for it to be false, as you shouldn't normally be using it; it's more
like a "null" state, it means "I don't know if we're equal or not". If
neither side knows whether they're equal, then they're presumed to be
unequal, but you can't determine that from a single call to __eq__.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
