Nick Coghlan added the comment:
There can be some interesting backwards compatibility consequences when adding
an __eq__ implementation to a class that was previously using the default ID
based __eq__:
- it becomes unhashable (unless you also add a suitable __hash__ definition)
- subclasses with additional significant state may start comparing equal, even
though their additional state is not taken into account by the new __eq__
function.
For the latter problem, you can alleviate it by comparing the instance
dictionaries rather than specific attributes:
>>> class Example:
... def __eq__(self, other):
... return self.__class__ == other.__class__ and self.__dict__ ==
other.__dict__
...
>>> a = Example()
>>> b = Example()
>>> a == b
True
>>> a.foo = 1
>>> a == b
False
>>> b.foo = 1
>>> a == b
True
(technically this can still change subclass behaviour if they're messing about
with slots, but there *is* such a thing as being *too* paranoid about backwards
compatibility)
The hashability problem is easy enough to handle just by mixing together the
hashes of the attributes of most interest:
def __hash__(self):
return hash(self.name) ^ hash(self.path)
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue19927>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
