Python2.x dictobject源码lookdict方法实现逻辑疑问咨询

你注意到的那两个判断，核心原因是中间执行的PyObject_RichCompareBool不是无副作用的纯比较操作：这个函数会调用键对象的__eq__魔法方法，而用户自定义的__eq__可以执行任意Python代码，完全可能在比较过程中修改当前正在查找的字典对象。

两个判断分别对应两种被修改的场景：

• ep0 == mp->ma_table：如果在__eq__里往字典插入了大量数据，触发字典扩容，字典会重新申请一块更大的内存作为新的哈希表，mp->ma_table会指向新的内存地址，我们之前缓存的旧表指针ep0就完全失效了。
• ep->me_key == startkey：如果在__eq__里删除、修改了当前探测到的这个条目ep的键，那我们之前保存的startkey已经和当前条目的键不一致了，刚才的比较结果也就没有意义了。

只要两个条件有一个不满足，就说明字典状态已经被修改，之前的查找上下文全部无效。

为什么用递归而不是循环继续探测 #

当上述字典被修改的情况发生时，我们之前缓存的哈希表指针ep0、掩码mask、探测位置i、空闲槽freeslot等所有局部状态全部失效，没办法在当前的循环里继续正确探测了。用递归直接重新调用lookdict是最简洁的实现：函数开头会重新读取字典的最新状态，初始化所有局部变量，不需要手动逐个重置变量，避免遗漏导致的bug。

注释指代的场景 #

就是上面说的，在执行键的相等比较时，__eq__方法里修改了字典的结构：比如增删元素触发扩容、修改当前探测的条目、清空字典等等操作，都会破坏当前查找的上下文，只能从头开始重新执行查找逻辑。
注释里提到的"恶意使用者可以阻止终止"是极端场景：如果有人自定义键的__eq__方法，每次执行时都修改一次字典结构，就会让查找逻辑一直递归下去，不过实际运行中Python的递归深度限制会阻断这种无限递归。

内容的提问来源于stack exchange，提问作者wangdq