python – 相同对象的缓慢平等评估(x == x)

有没有什么原因x == x不快速评估？我希望__eq__会检查它的两个参数是否相同,如果是,则立即返回True.但它不这样做：

s = set(range(100000000))
s == s # this doesn't short-circuit, so takes ~1 sec

对于内置函数,x == x总是返回True我想？对于用户定义的类,我想有人可以定义不满足此属性的__eq__,但是有什么合理的用例吗？

我想要x == x被快速评估的原因是因为当 memoizing functions with very large arguments ：

from functools import lru_cache
@lru_cache()
def f(s):
    return sum(s)
large_obj = frozenset(range(50000000))
f(large_obj) # this takes >1 sec every time

请注意,@lru_cache对于大对象反复慢的原因不是因为需要计算__hash__(这只是一次完成,然后由@jsbueno硬缓存为 pointed out ),而是因为字典的哈希表需要执行__eq__时间来确保它在桶中找到正确的对象(散列的相等性明显不足).

更新：

对于三种情况,分开考虑这个问题似乎是值得的.

1)用户定义的类型(即不是内置/标准库).

正如@donkopotamus所指出的,有些情况下x == x不应该评估为True.例如,对于numpy.array和pandas.Series类型,结果有意不能转换为布尔值,因为不清楚自然语义应该是什么(False表示容器为空,还是表示其中的所有项目都为False？ ).

但是在这里,python不需要做任何事情,因为如果适用,用户总是可以短路x == x比较：

def __eq__(self, other):
  if self is other:
    return True
  # continue normal evaluation

2)Python内置/标准库类型.

a)非集装箱

对于所有我知道的短路可能已经实施了这种情况 – 我不能告诉,因为任何一种方式它是超级快.

b)容器(包括str).

正如@Karl Knechtel所言,如果在自我不是其他的情况下,额外的开销超过了短路节省,则短路可能会损害总体性能.虽然在理论上可能,即使在这种情况下,开销相对较小(容器比较永远不会超快).当然,在短路有帮助的情况下,节省的费用也会很大.

BTW,结果是str做短路：比较巨大的相同的字符串是即时的.

可能会这么愚蠢：

>>> float("NaN") == float("NaN")
False

另一个“不合理的用例”：

>>> bool(numpy.ma.masked == numpy.ma.masked)
False

甚至：

>>> numpy.arange(10) == numpy.arange(10)
array([ True,  True,  True,  True,  True,  True,  True,  True,  True,  True], dtype=bool)

有大胆的甚至不能转换成bool！

因此,x == x绝对不会自动短路成为真实的范围.

离开课程

不过以下可能是一个很好的问题：

Why doesn’t set.__eq__ check for instance identity?

那么人们可能会想,因为一套S可能包含NaN,而NaN不能等于自己,那么这样一个集合S就不能等于自己呢？调查：

>>> s = set([float("NaN")])
>>> s == s
True

嗯,这很有趣,特别是因为：

>>> {float("NaN")} == {float("NaN")}
False

这种行为是由于 Python 对 sequences to be reflexive 的渴望.