assymetry between a == b and a.__eq__(b)
Nick Coghlan
ncoghlan at email.com
Fri Dec 3 18:48:26 EST 2004
Steven Bethard wrote:
> Mel Wilson wrote:
>
>> In article <Qtqrd.177755$HA.59149 at attbi_s01>,
>> Steven Bethard <steven.bethard at gmail.com> wrote:
>>
>>> I believe what Peter Otten was pointing out is that calling __eq__ is
>>> not the same as using ==, presumably because the code for == checks the
>>> types of the two objects and returns False if they're different before
>>> the __eq__ code ever gets called.
>>
>>
>>
>> Doesn't seem to:
>
> [snip]
>
> Check his example:
>
> http://mail.python.org/pipermail/python-list/2004-November/252660.html
I suspect that example is due to the rule that "A op B" can be passed to any of
the following, depending on the operator and the types of A and B:
A.__op__(B)
B.__op__(A)
B.__rop__(A)
The latter two get invoked when B is a proper subclass of A (using 'op' for
commutative operations, and 'rop' for potentially non-commutative ones). This is
so that subclasses can interact with parent classes correctly.
So, in Steven's original code, B.__eq__(A) was invoked, and returned False
(since A was the parent class of B, not a subclass).
Cheers,
Nick.
More information about the Python-list
mailing list