Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #52125

Re: Bug? ( () == [] ) != ( ().__eq__([]) )

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

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 <rosuav@gmail.com> wrote:

> On Sun, Aug 4, 2013 at 11:35 PM, Markus Rother <python@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

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread

Thread

Re: Bug? ( () == [] ) != ( ().__eq__([]) ) Shiyao Ma <i@introo.me> - 2013-08-07 17:24 +0800

csiph-web