Python 的哈希契约：为什么 list 不能当字典的键-北京尧图网络

原文链接Python 的哈希契约为什么 list 不能当字典的键 - 码日新 · 每日文章Python 的哈希契约为什么 list 不能当字典的键上周帮同事看一个缓存问题他用列表拼了个 key运行时直接抛出TypeError: unhashable type: list。改成元组就好了。但另一个更隐蔽的 bug 是对象明明还在字典里却怎么也取不出来。这两个问题其实指向同一条规则——能当字典键的东西必须遵守哈希契约。一次d[key]到底发生了什么Python 的dict本质是哈希表。执行d[key]时解释器大致做两件事计算hash(key)用结果定位到某个桶在桶里用比较候选键。为了效率比较之前还会先看是不是同一个对象身份相同就直接命中。classKey:def__init__(self,value):self.valuevaluedef__hash__(self):print(fhash({self.value}))returnhash(self.value)def__eq__(self,other):print(feq({self.value},{getattr(other,value,other)}))returnisinstance(other,Key)andself.valueother.value d{Key(1):a}print(--- 查找 ---)print(d[Key(1)])输出hash(1) --- 查找 --- hash(1) eq(1, 1) a这也解释了字典的两条硬性要求相等的键必须有相同的哈希键的哈希在它待在字典里的时候不能变。违反任何一条字典就可能找不到东西。list 不行tuple 也不一定行list是可变的所以 Python 直接把它的__hash__设成了Noneprint(list.__hash__)# Noneprint(hash((1,2)))# 正常print(hash((1,[2])))# TypeError: unhashable type: list元组本身不可变但它的哈希是由元素组合出来的。只要里面有一个元素不可哈希整个元组就不可哈希。这个规则会递归传递hash((1,(2,3)))# 可以hash((1,(2,[3])))# TypeError所以“把 list 改成 tuple”并不是万能药。如果列表里还藏着列表或字典照样会失败。写了__eq____hash__就没了自定义类默认按身份哈希也就是基于id()。两个内容相同的对象默认就是两个不同的键。一旦你实现了__eq__Python 会把__hash__置为None除非你也显式实现它classUser:def__init__(self,uid,name):self.uiduid self.namenamedef__eq__(self,other):returnisinstance(other,User)andself.uidother.uidprint(User.__hash__)# None# hash(User(1, a)) # TypeError: unhashable type: User补上__hash__时字段必须和__eq__保持一致classUser:def__init__(self,uid,name):self.uiduid self.namenamedef__eq__(self,other):returnisinstance(other,User)andself.uidother.uiddef__hash__(self):returnhash(self.uid)这里name可变但不参与相等判断也不参与哈希所以修改它不会破坏字典。如果整个对象都该不可变可以用冻结的 dataclassfromdataclassesimportdataclassdataclass(frozenTrue)classUser:uid:intname:str默认的dataclass(frozenTrue)会生成__eq__和__hash__并阻止属性赋值。注意它的哈希会用到所有参与比较的字段如果只想按uid判等还是得手写。最隐蔽的坑键被修改了下面这段代码不会报错但会让键“消失”classMutableKey:def__init__(self,value):self.valuevaluedef__hash__(self):returnhash(self.value)def__eq__(self,other):returnisinstance(other,MutableKey)andself.valueother.value kMutableKey(1)d{k:one}k.value2print(kind)# Falseprint(d.get(k))# Noneprint(list(d))# 键还在字典里print(d[k])# KeyError字典并没有坏。它只是按照新的哈希去 2 号桶找而当初存进去的是 1 号桶。旧条目还在但已经无法通过这个键访问。解决办法不是“改完再 rehash”而是别让键变用不可变对象当键只把不会变的字段放进__hash__真需要可变键就先删除旧键改完再插回去。相等但哈希不同也会出事还有一种更隐蔽的写法__eq__按值比较__hash__却按身份生成。classBadKey:def__init__(self,value):self.valuevaluedef__eq__(self,other):returnisinstance(other,BadKey)andself.valueother.valuedef__hash__(self):returnid(self)a,bBadKey(1),BadKey(1)print(ab)# Trueprint(hash(a)hash(b))# Falsed{a:a}print(d[b])# KeyErrorprint(len({a,b}))# 2两个对象相等却被放进了不同的桶。字典既无法保证“一个键只出现一次”也无法通过等价的键找到值。顺带一提1、1.0和Trued{1:int,1.0:float,True:bool}print(d)# {1: bool}三者相等哈希也相同所以它们是同一个键后写入的覆盖先写入的。这不是 bug而是哈希契约的正常结果。NaN 则是另一个极端nanfloat(nan)d{nan:x}print(d[nan])# x身份相同直接命中print(d[float(nan)])# KeyError新对象既不等于自己哈希也不同所以别拿 NaN 当键。如果数据里可能出现 NaN先清洗再入字典。实践清单想用的键能否直接用建议int/str/bytes是不可变哈希稳定tuple视元素而定元素必须全部可哈希list/dict/set否可变__hash__为Nonefrozenset是元素必须可哈希普通自定义对象是默认按id()身份语义实现了__eq__但没实现__hash__否__hash__会被置为None几条可以直接照做的建议组合键优先用元组嵌套的 list 转成 tupledict 转成tuple(sorted(d.items()))set 转成frozenset。自定义值对象要同时实现__eq__和__hash__并保证两者使用同一组字段。对象放进字典后不要修改参与哈希的字段。需要身份语义时就用默认的object.__hash__和object.__eq__不要多写。调试时可以直接打印Cls.__hash__或者在修改前后对比hash(k)。回到开头那个缓存把 list 换成 tuple 只是第一步真正要确认的是这个 key 在缓存生命周期里不会变。字典不会帮你检查这件事它只负责按照你给的哈希去找。哈希契约是调用方和维护者之间的约定Python 把签字笔递给了你。参考文档Primers 编程伙伴/Python/内建函数/typePrimers 编程伙伴/Python/内建函数/printPrimers 编程伙伴/Python/内建函数/hashPrimers 编程伙伴/Python/内建函数/getattrPrimers 编程伙伴/Python/内建函数/isinstancePrimers 编程伙伴/Python/内建函数/listPrimers 编程伙伴/Python/内建函数/intPrimers 编程伙伴/Python/内建函数/strPrimers 编程伙伴/Python/内建函数/idPrimers 编程伙伴/Python/内建函数/lenPrimers 编程伙伴/Python/内建函数/floatPrimers 编程伙伴/Python/内建函数/bool

Python 的哈希契约：为什么 list 不能当字典的键

相关推荐

最小操作次数使数组元素相等 III【力扣LeetCode 每日一题】

asyncio.run() cannot be called from a running event loop：在 async 函数里该怎么改

Opus 4.8快速模式11月30日移除：两条迁移路径怎么选？

更多资讯

Java Web批量下载打包ZIP：流安全与中文文件名实战方案

数据湖存储架构设计与优化实战指南

具身智能操作系统：架构设计与工程实践

自动驾驶多传感器时空对齐技术实践

HarmonyOS智能座舱开发：分布式架构与实时性优化

对话式诊断系统AMIE：从主诉到鉴别诊断的对话机制与评测体系

今日更新

多智能体协作系统架构设计与实践优化

大模型系统性入门实战指南：从原理到部署微调的全链路路线

鸿蒙文件系统沙箱机制解析与开发实践

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？