Which class's comparison function is called?

[Bill Jackson]

For example,

class A:
def __init__(self,a):
self.a = a
def __eq__(self, other):
return self.a == other.a

class B:
def __init__(self,b):
self.b = b
def __eq__(self, other):
return self.b == other.b


A(1) == B(1)
---> AttributeError: B instance has no attribute a

B(1) == A(1)
---> AttributeError: A instance has no attribute b

From the above, it seems that Python always uses the function defined
by the class on the LEFT. However, I don't understand the following then:

A(1) == 3
---> AttributeError: 'int' object has no attribute a

3 == A(1)
---> AttributeError: 'int' object has no attribute a

Can someone explain this? I expected 3 == A(1) to use the __eq__
function defined for 'int' objects.

 

[Basilisk96]

Try adding the following diagnostic messages to your __eq__ class
definitions, and see if it will dispel the confusion for the four
equality tests you have tried:

class A:
def __init__(self,a):
self.a = a
def __eq__(self, other):
print "(A) self:%r, other:%r" %(self.__class__, other.__class__)
return self.a == other.a

class B:
def __init__(self,b):
self.b = b
def __eq__(self, other):
print "(B) self:%r, other:%r" %(self.__class__, other.__class__)
return self.b == other.b

You are correct, Python evaluates the expressions from left to right.

A(1) == B(1)
---> AttributeError: B instance has no attribute a

The left instance's __eq__ method is invoked, which says, "is the
value of self.a equal to the value of other.a ?"; and the answer is,
"other has no attribute a to compare with self.a!" so you get an
exception.

B(1) == A(1)
---> AttributeError: A instance has no attribute b

Same case as the first, but the instances have switched places...

A(1) == 3
---> AttributeError: 'int' object has no attribute a

Same case as the first, but 'other' is now an object of type 'int',
which inherently has no attribute 'a'. A similar effect will manifest
when you will try to do:
B(1) == 3
---> AttributeError: 'int' object has no attribute 'b'

3 == A(1)
---> AttributeError: 'int' object has no attribute a

Can someone explain this? I expected 3 == A(1) to use the __eq__
function defined for 'int' objects.

This last one is interesting.
The '__eq__' method is not defined for 'int' objects. The '=='
operator tests for value equivalence. As before, the left side is
evaluated first, and evaluates to a simple integer value. No special
methods are called. Now, the right side's value is evaluated. Since
equality is being tested, the right side's __eq__ method is called,
with the (self, other) arguments being (<instance of class A>, 3)
respectively. Since 'int' is the 'other' argument in this case, it
again results in the exception "no attribute 'a' ".


The last of the four tests that you have mentioned is giving you the
trouble, right? Perhaps the solution is to add type-checking to the
__eq__ method?

(untested)
def __eq__(self, other):
if isinstance(other, int):
tmp = other
else:
tmp = other.a # (other.b in class B definition)
return self.a == tmp # (self.b in class B definition)

Cheers,
-Basilisk96

 

[Steven D'Aprano]

On Tue, 05 Jun 2007 19:16:53 -0700, Bill Jackson wrote:

[snip]

From the above, it seems that Python always uses the function defined
by the class on the LEFT. However, I don't understand the following
then:

[snip]

In general, infix operators like + - * etc. will call the appropriate
methods __add__ __sub__ etc. for the class on the LEFT. If the class on
the left doesn't define such a method, the class on the right will be
called with __radd__ __rsub__ etc.

(There are complications -- see here for details:
http://docs.python.org/ref/numeric-types.html )

The rules for comparison functions are a little more complicated, and by
a little I mean a lot. You can start here:

http://docs.python.org/ref/customization.html


The exception to the "try the left operand first, then try the right
operand" rule happens when the left operand is a built-in like int,
float, etc. In that case, if Python called int.__add__ (or whatever the
method was), your class would likely never be called, which makes it hard
for you to over-ride the operator. So Python calls your methods first.

And don't forget that if you are inheriting from object, object will
likely define default rich comparisons that probably don't do what you
expect.