assymetry between a == b and a.__eq__(b) (WAS: pre-PEP generic objects)

[Steven Bethard]

Peter Otten wrote:
Steven Bethard wrote:
def __eq__(self, other):
   """x.__eq__(y) <==> x == y"""
   return (isinstance(other, self.__class__)
           and self.__dict__ == other.__dict__)

This results in an asymmetry:
from bunch import Bunch
class B(Bunch): pass
...
B().__eq__(Bunch())
False
Bunch().__eq__(B())
True
With indirect use of __eq__() this puzzling behaviour disappears:
B() == Bunch()
False
Bunch() == B()
False
Whether this is intended, I don't know. If someone can enlighten me...
It does look like it's at least documented:
http://docs.python.org/ref/comparisons.html
"The operators <, >, ==, >=, <=, and != compare the values of two 
objects. The objects need not have the same type. If both are numbers, 
they are converted to a common type. Otherwise, objects of different 
types always compare unequal, and are ordered consistently but arbitrarily."

This sounds like using "==" makes a guarantee that objects of different 
types will compare unequal, while my __eq__ method (using isinstance) 
did not make this guarantee.

I tried to check the C code to verify this (that different classes are 
guaranteed to be unequal) but rich comparisons make that code pretty 
complicated.

Steve
--
http://mail.python.org/mailman/listinfo/python-list