定义__eq__的类型是不可散列的吗？

将功能移植到程序的Python 3.1 fork时遇到一个奇怪的错误。我将其缩小为以下假设：

与Python 2.x相比，在Python 3.x中，如果对象具有__eq__方法，则该对象将自动取消哈希。

这是真的？

这是Python 3.1中发生的情况：

>>> class O(object):
...     def __eq__(self, other):
...         return 'whatever'
...
>>> o = O()
>>> d = {o: 0}
Traceback (most recent call last):
  File "<pyshell#16>", line 1, in <module>
    d = {o: 0}
TypeError: unhashable type: 'O'

后续问题是，如何解决我的个人问题？我有一个对象ChangeTracker，该对象存储一个WeakKeyDictionary指向多个对象的对象，并为每个对象提供过去某个特定时间点的酱菜堆的值。每当检入现有对象时，变更跟踪器都会说出其新的泡菜与旧的泡菜是否相同，因此说明对象在此同时是否发生了变化。问题是，现在我什至无法检查给定的对象是否在库中，因为这使它引发有关该对象不可哈希的异常。（因为它有一种__eq__方法。）如何解决此问题？

是的，如果您定义__eq__，则默认值__hash__（即对内存中对象的地址进行哈希处理）将消失。这很重要，因为散列必须与相等性保持一致：相等的对象也需要对其进行散列。

解决方案很简单：只需将define__hash__和define一起定义即可__eq__。

本段来自http://docs.python.org/3.1/reference/datamodel.html#object。杂凑

如果重写的类__eq__() 需要保留__hash__()父类的实现 ，则必须通过设置明确告知解释器__hash__ = <ParentClass>.__hash__。否则，__hash__()将被阻止继承，就像__hash__已显式设置为None一样。

在以下位置查看Python 3手册object.__hash__：

如果一个类没有定义一个__eq__()方法，它也不应该定义一个__hash__()操作。如果定义__eq__()但__hash__()未定义，则其实例将不能用作可哈希集合中的项目。

重点是我的。

如果你想偷懒，听起来就像你可以定义 __hash__(self)return id(self)：

用户定义的类默认具有__eq__()和__hash__()方法。使用它们，所有对象比较不相等（它们自身除外）并x.__hash__()返回id(x)。

我不是python专家，但是当您定义eq方法时，您还必须定义一个hash方法（计算对象的hash值）是否有意义，否则，使用hashing机制不知道它是命中相同的对象还是具有相同哈希值的不同对象。实际上，这是相反的，它可能最终会为您认为相等的对象计算不同的哈希值__eq__方法。

我不知道该哈希函数是什么，__hash__也许吗？:)