Sorry. I don't quite get it. As you said, it first tries, leftOperand.__eq__(rightOperand) then if it returns NotImplemented, it goes to invoke rightOperand.__eq__(leftOperand). But for any reason, [] == () returns false, why?
On Mon, Aug 5, 2013 at 7:06 AM, Chris Angelico <ros...@gmail.com> 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 > -- http://about.me/introom
-- http://mail.python.org/mailman/listinfo/python-list
