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): passFalseB().__eq__(Bunch())Bunch().__eq__(B())True
With indirect use of __eq__() this puzzling behaviour disappears:
FalseB() == Bunch()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