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


Groups > comp.lang.python > #51965 > unrolled thread

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

Started byMarkus Rother <markus.rother@web.de>
First post2013-08-05 16:58 +0200
Last post2013-08-05 16:58 +0200
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Bug? ( () == [] ) != ( ().__eq__([]) ) Markus Rother <markus.rother@web.de> - 2013-08-05 16:58 +0200

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

FromMarkus Rother <markus.rother@web.de>
Date2013-08-05 16:58 +0200
SubjectRe: Bug? ( () == [] ) != ( ().__eq__([]) )
Message-ID<mailman.212.1375714689.1251.python-list@python.org>
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 <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
>

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web