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