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
