★ FEATURED ARTICLE TypeError: tuple object does not support item assignment如果你写过一阵子 Python大概率撞见过这行红字。我第一次碰到它是在刚入门那会儿写了个t[0] 100以为元组跟列表一样能“修修补补”结果直接被解释器教育了。后来我才意识到元组tuple就是 Python 里那个“看起来跟列表长得像、用起来却处处跟你较劲”的数据类型。元组本质上是“不可变的列表”。它用圆括号把一组元素包起来元素之间用逗号分隔可以放数字、字符串、列表甚至再套一层元组。它能索引、能切片、能遍历唯独不能增、删、改。这份“不能改”听起来像限制实际上一旦你用对了地方反而会让代码少掉一大堆莫名其妙的 bug。这篇文章适合两类人一类是刚开始学 Python、准备把基础数据类型逐个啃一遍的新手另一类是已经写了段时间代码、但还没搞明白元组到底该在什么时候用的开发者。我会从元组的定义一路拆到解包、嵌套、命名元组这些进阶玩法最后一章专门盘点我在实际项目里踩过的元组坑。全程不需要复杂环境打开一个 Python 解释器跟着敲一遍基本就能把这些内容消化掉。1. 元组是什么先搞懂不可变序列这个概念1.1 元组的定义括号、逗号和元素的组合方式元组是 Python 的内置序列类型跟列表、字符串一样都属于“有序排列的一串数据”。定义一个元组最直观的方式就是圆括号加逗号 type(()) class tuple t (1, 2, 3) type(t) class tuple甚至不加括号也可以直接用逗号隔开就能造出元组 t 1, 2, 3 type(t) class tuple这和列表那种“必须用方括号”的语法习惯很不一样。初学者最容易忽略的一个点就是真正让一个对象成为元组的不是括号而是逗号。括号更多是一个视觉包装让人一眼看出“这里是一组聚合数据”。至于“为什么元组能用括号、也能不用括号”语言本身并没有太玄妙的设计意图就是为了让语法更灵活少数派写法在某些场景下反而很顺手比如函数返回多个值时自动打包成元组。从内存布局来看你可以把元组想象成一条贴着位置编号的陈列柜编号从 0 开始每个柜位只能放一个对象柜位数量在创建那一刻就锁死了。这个形象化的理解能帮你绕开很多后续的坑尤其是当你试图修改元组却报错的时候脑子里浮现的不是抽象概念而是一排“封死的柜位”心里一下就通透了。1.2 不可变特性元组为什么“锁”住了数据“不可变”三个字听起来有点专业课的味道实际解释起来很简单你无法往元组里塞新元素无法删除某个元素也无法替换某个位置上的元素。试试直接改会得到什么结果 t (1, 2, 3) t[0] 100 TypeError: tuple object does not support item assignment t.append(4) AttributeError: tuple object has no attribute append t.remove(2) AttributeError: tuple object has no attribute remove注意最后一个报错元组连remove方法都不存在因为它天生就没有删除的能力。跟列表那套append、remove、pop的“可变操作全家桶”相比元组只保留了读取和查询类的方法。那这份“不能改”到底换来了什么数据安全。元组一旦创建内容就不会被意外改动。跨模块传参、多人协作时这种“只读”属性特别重要别人拿到的元组就算想改也改不了。可哈希性。字典键和集合元素要求对象必须可哈希而可哈希的前提之一就是对象创建后哈希值不能变。元组的不可变特性刚好满足了这一点更细节的讨论留到 4.3 节。性能更优。不可变意味着更紧凑的内存布局不需要像列表那样预留扩容空间读写速度也更轻快。生活里找个类比的话元组像是一张印好的名片名字、职位、电话印上去就固定了你不能在名片上用笔随便改职位列表更像一张草稿纸随时可以涂改、撕掉、重写。写代码的时候有些数据天生就不该被改动比如坐标点、RGB 颜色值、函数返回的多项结果这时候用元组表达“这里的结构是固定的”就特别合适。1.3 元组与列表一张表看懂两者的分工列表和元组天天被一起提起因为确实太像了但它们的定位完全不同。我把关键差异整理成了下面这张表对比维度元组 tuple列表 list书写语法圆括号或直接逗号分隔方括号可变性不可变可变增、删、改不支持全面支持可哈希性内部元素都可哈希时可哈希不可哈希内存占用更小更大典型场景固定结构数据、字典键、函数返回值动态数据集合、批量处理打个比方。列表像一个可以随时加座的餐厅大厅客人来了就加椅子走了就撤椅子元组像电影院放映厅的座位建好的时候多少个座位就是多少个座位编号也固定你想多塞一个座位或者把两边坐椅换成沙发那不行。实际编码时怎么选规则并不复杂如果数据在程序运行过程中需要频繁地增删、修改比如收集日志、拼接列表、动态生成菜单用列表如果数据的结构是固定的比如一个三维空间的点、一个人的基本信息、一个函数要返回的多项结果用元组。我个人写项目时还有一个“默认倾向”能写元组的地方我尽量写元组因为元组带来的“不可变”约束其实是免费的保险能防止自己或队友手滑改错数据。等到真遇到必须修改的场景再换成列表也为时不晚。2. 从创建到读取元组的基础操作全图解2.1 创建元组的三种方式含单元素大坑创建元组有三个常用姿势我直接摆出来# 方式一空元组 empty () # 方式二普通元组圆括号包裹 point (10, 20) # 方式三省略圆括号逗号分隔 point 10, 20第三种写法在函数返回多个值时最典型其实你不写括号Python 也会帮你打包成元组返回。平时写代码为了可读性还是会加上括号但心里得清楚括号不是元组的“准生证”逗号才是。这里有个几乎人人踩过的坑——单元素元组必须带逗号 a (5) type(a) class int # 这不是元组是整数 b (5,) type(b) class tuple # 这才是元组原因也不难理解在 Python 语法里(5)只是用括号把整数 5 括起来括号在这里扮演的是“表达式分组”的角色比如(1 2) * 3里的括号而不会凭空创造元组。只有后面的逗号才是一个真正的信号告诉解释器“这是一个含单个元素的元组”。这个坑的实际杀伤力很大尤其是函数里写return (x)想返回单元素元组、结果返回了一个普通整数的时候下游一解包就会报错。最好的排查方式就是print(type(...))一眼就能看出到底是不是元组。另外tuple()这个工厂函数也可以用来创建元组参数是可迭代对象 tuple([1, 2, 3]) (1, 2, 3) tuple(abc) (a, b, c)如果你手里已经有列表想转成不可变结构直接tuple(列表)是最省事的方式。2.2 索引与切片访问元组内元素的正确姿势元组和列表的读取方式几乎一模一样都是通过索引和切片。先看索引 t (10, 20, 30, 40, 50) t[0] # 第一个元素 10 t[-1] # 最后一个元素 50 t[-2] # 倒数第二个元素 40索引从 0 开始这是所有序列类型的通用约定。负数索引是从尾部往前数-1是最后一个元素。这个设计在处理不知道长度、只想拿最后一个元素的场景里特别方便。再看切片切片返回的是一个新的元组而不是原元组的视图 t[1:4] # 从索引 1 到索引 3左侧含右侧不含 (20, 30, 40) t[::2] # 步长为 2 (10, 30, 50) t[::-1] # 倒序取全部 (50, 40, 30, 20, 10)“左侧含右侧不含”的规则和列表完全一致Python 的切片统一采用这种半开区间设计目的是让切片长度更容易计算比如t[1:4]的长度就是4 - 1。新手容易迷惑的一点是索引越界会报错切片越界却不会。 t[100] IndexError: tuple index out of range t[1:100] (20, 30, 40, 50)直接取第 100 个元素解释器会扔出IndexError因为它确实没有这个元素但切片不一样Python 会自动把越界的边界收回到元组的有效范围内只返回已有的部分。这个设计初看有点不一致实际上相当贴心——循环里动态截取数据时完全不用担心边界算错了导致程序崩溃。2.3 拼接、重复、成员判断元组的“只读”操作家族除了索引和切片元组还支持一系列“只读”操作。先说拼接和重复 (1, 2) (3, 4) (1, 2, 3, 4) (1, 2) * 3 (1, 2, 1, 2, 1, 2) (1, 2) * 0 ()会把两个元组首尾相接生成一个新元组*会把元组重复 N 次。注意这些都是“生成新元组”原元组不会有一丁点变化。这跟列表的行为一样但如果你习惯了列表的append那种原地修改的风格用元组时要改一下思维所有操作都是返回新对象。成员判断也是常用操作 3 in (1, 2, 3) True 10 not in (1, 2, 3) Truein的底层就是一个挨一个遍历所以时间复杂度是 O(n)。如果元素数量级很大且需要频繁查询那你应该考虑集合而不是元组集合的哈希查找是 O(1)。内置函数也直接覆盖了元组的需求 len((1, 2, 3, 4)) 4 max((3, 7, 2)) 7 min((3, 7, 2)) 2 sum((1, 2, 3)) 6最后是元组自带的两个查询方法 t (1, 2, 2, 3) t.count(2) 2 t.index(3) 3count返回某个元素出现的次数index返回某个元素首次出现的索引位置如果找不到则抛ValueError。这套操作组合下来元组的“查询能力”其实不比列表弱只是没有修改能力罢了。3. 元组的进阶玩法解包、嵌套与命名元组3.1 元组解包一行代码拆开所有元素元组最让人上头的特性之一是解包unpacking。所谓解包就是把元组里的元素按顺序批量赋值给一系列变量 person (张三, 25, 工程师) name, age, job person name 张三 age 25 job 工程师一行代码就把三个元素分别装进了三个变量比挨个person[0]、person[1]再赋值要清爽太多。如果你学过其他语言这就像给数组做了个“自动拆箱”。解包还有一个进阶用法星号捕获。当元组长度不确定你只关心前几个或后几个元素时用星号变量接住剩下的一堆 first, *rest (1, 2, 3, 4, 5) first 1 rest [2, 3, 4, 5] *leading, last (1, 2, 3, 4, 5) leading [1, 2, 3, 4] last 5注意rest和leading是用列表接住的不是元组。这是 Python 的固定行为这样设计是为了让被捕获的部分保持“后续可能修改”的灵活性。解包经常配合循环使用比如枚举元组for index, value in enumerate((10, 20, 30)): print(index, value)再比如同时遍历字典的键和值d {name: 李四, age: 28} for key, value in d.items(): print(key, value)d.items()返回的每个元素本质上就是一个元组for key, value in ...这个写法其实就是在做元组解包。看懂这一点你就再也不会觉得for key, value是什么魔法了。3.2 多返回值与交换变量函数返回的经典搭档在 Python 里写一个返回多个值的函数最自然的做法就是直接返回多个值def get_user_info(): return 李四, 28, 北京 name, age, city get_user_info() print(name, age, city) # 李四 28 北京表面上看是“返回了三个值”实际上 Python 在底层把它们打成了一个元组(李四, 28, 北京)。所以这种写法和下面这种写法完全等价def get_user_info(): return (李四, 28, 北京)那么问题来了函数返回多个结果时为什么不返回列表关键就在于元组的不可变性。函数把结果交给调用方后如果返回的是一个列表调用方就能随意append、remove、改元素届时函数内辛辛苦苦拼出来的结构就被破坏了。而元组把结构锁死调用方只能读取这相当于给自己留了一个“结构完整性保障”。另一个经典是变量交换 a, b 1, 2 a, b b, a a 2 b 1在其他语言里交换两个变量通常需要一个临时变量中转Python 里直接一行搞定。它的底层其实是元组右边的b, a先被求值生成一个元组(2, 1)然后再解包赋值给a, b。整个过程不会出现“赋值一半被覆盖”的问题因为右侧的求值会先一步完成。3.3 嵌套元组处理二维及更高维的数据结构元组里可以再放元组这就是嵌套。嵌套之后数据就有了一层“结构感” t ((1, 2), (3, 4), (5, 6)) t[1] (3, 4) t[1][0] 3t[1]拿到的是第二个元素也就是一个元组(3, 4)再对它加一个[0]就能取到里面的3。这个过程跟剥洋葱一样一层一层往里取。嵌套元组的实际应用很常见。比如一组二维平面上的坐标点用((10, 20), (30, 40), (50, 60))存起来既直观又安全。再比如一张固定格式的表格数据每一行都是一个元组table ( (订单-1001, 键盘, 2), (订单-1002, 鼠标, 1), (订单-1003, 显示器, 1), )若要遍历整张表并解包每一行for order_id, product, quantity in table: print(order_id, product, quantity)这比用列表套列表更让人放心——因为表格结构是固定的你不会在写代码过程中不小心删掉一列、换掉一列。嵌套内容也不要求全是元组元组里可以混着放列表、字典。比如一条混合的记录record (订单-1001, {商品: 键盘, 数量: 2}, [白灯, 青轴])能放可变对象是元组的灵活性但这也会带来一个隐蔽的坑我会在 4.2 节专门细说。3.4 命名元组给元组的每个位置起个名字普通元组的短板是只能靠索引访问p[0]表示 x 坐标、p[1]表示 y 坐标代码读起来要靠记忆。如果你希望既有元组的轻量和不可变又希望字段能拥有名字命名元组就是答案。命名元组来自标准库的collections模块 from collections import namedtuple Point namedtuple(Point, [x, y]) p Point(3, 5) p.x 3 p.y 5 p[0] 3namedtuple的本质是一个工厂函数它接收一个类名和一个字段名列表返回一个新的类。上面例子里的Point其实是一个类p是它创建出来的实例。这个实例是元组的一个子类所以元组的索引、解包、遍历它全都支持同时多出了通过字段名访问的能力。再来一个完整点的例子Student namedtuple(Student, [name, age, score]) s Student(王五, 18, 96) print(s.name, s.age, s.score) # 王五 18 96用命名元组替代字典存储轻量记录最直接的好处是访问方式从s[name]变成了s.name写起来更短而且不会因为敲错字符串键而偷偷返回None。要改某个字段的值用_replace方法生成一个拷贝副本 s2 s._replace(score99) s Student(name王五, age18, score96) s2 Student(name王五, age18, score99)_replace不会修改原对象而是返回一个新实例这跟元组的不可变思路一脉相承。日常开发中当你发现自己写了一个只用来装数据、没有方法的小类时很多情况下用namedtuple会更省事。4. 元组的边界与陷阱哪些坑我替你踩过了4.1 单元素元组陷阱忘了逗号的后果前面创建那节我提过单元素元组必须加逗号这里我要单独拎出来讲因为它在实战中太容易触发连环 bug。假设有个函数要返回“查询结果里的第一项”预期返回一个元组方便上游统一解包def get_first(): item (100) # 括号想体现“元组感”其实写成这样是整数 return item result get_first() name, result # 上游做解包想拿一个元素运行这段代码解释器大概率会报TypeError: cannot unpack non-iterable int object。原因就是(100)根本不是一个元组它只是整数 100 外面加了层括号。正确的写法是item (100,)括号在前、逗号在后缺一不可。这个问题我自己在项目中遇过不止一次排查思路也很简单先print(type(result))确认类型再看报错信息。信息里如果出现iterable字样多半就是返回了不可迭代的对象。解决方式就是在单元素后面补上逗号。这里还有一个小知识点你可以在解释器里直观感受一下两者的差别 print((5)) 5 print((5,)) (5,)输出结果一个是5一个是(5,)一眼就能区分。这也是为什么 Python 代码风格指南里明确建议“即使在非必要时也保留单元素元组的逗号”——这个逗号不是给你看的是给解释器看的。4.2 可变元素陷阱元组里放列表锁不住如果说“元组不可变”四个字给了你“里面所有东西都不可变”的印象那接下来这个坑最容易颠覆你的认知。看这段代码 t (1, [2, 3], 4) t[1].append(5) t (1, [2, 3, 5], 4)成功了元组里的第二个元素变成了[2, 3, 5]。这不是说元组可变而是因为元组里存的是那个列表对象的“引用”而不是列表内容的快照。元组本身锁定的是每个位置的引用地址列表对象里有什么跟元组无关。引用还是同一个引用没有违规所以没有任何报错。用前面的陈列柜类比理解更清楚元组是那排陈列柜每个柜位上写着的是“指向某个对象”的编号。编号不能改但编号指向的那个房间内部怎么装修、里面放没放新家具柜子本身管不着。这个特性带来的实际影响有两个方向。第一你如果把“完全不可变”的需求寄托在元组上内部却放了列表或字典那么安全性其实是不达标的数据照样能被修改。真正的“深度不可变”只能由嵌套的元组来保证比如(1, (2, 3), 4)。如果你创建元组时手里是列表想转成稳妥的纯不可变结构可以提前做一次转换raw [2, 3] t (1, tuple(raw), 4) # 把可变列表转成元组再放入第二哈希层面的连锁反应。一个内部含列表的元组连字典键都当不了因为它不可哈希。这个问题我放在下一节讲。4.3 元组做字典键与集合元素为什么它能而列表不能Python 的字典键和集合元素要求对象必须可哈希。简单理解哈希就像给对象算一个“唯一身份证号”每次算出来的结果必须稳定。列表是可变的列表里的元素变了理论上它的哈希值也应该变这就导致它没法当键——放着放着键的“身份证号”就变了字典就找不到它了。所以 Python 直接规定列表不可哈希。元组因为不可变正常情况下哈希值稳定所以能当键 hash((1, 2, 3)) -3550055125485641917 hash([1, 2, 3]) TypeError: unhashable type: list这里要补充一个关键限定条件不是所有元组都可哈希。只有当元组内部的所有元素都可哈希时元组整体才可哈希。举个例子 hash((1, 2, 3)) -3550055125485641917 hash((1, [2, 3])) TypeError: unhashable type: list因为[2, 3]不可哈希整个元组就被“拉下水”了。元组作为字典键的经典应用是坐标映射。比如游戏里一张地图(x, y)坐标作为键对应地点名字作为值map_data { (10, 20): 起点森林, (30, 40): 岩石营地, (50, 60): 废弃矿洞, } print(map_data[(10, 20)]) # 起点森林列表不能完成同样的事情因为[10, 20]连创建字典键这关都过不了。元组做键还有一个隐藏好处它能天然组合多个维度做数据分组。你想按年和月统计订单量直接用(year, month)当键生成的字典结构清晰又直观。4.4 性能对比与应用场景什么时候用元组什么时候用列表性能这个东西写小脚本时感觉不明显但处理大规模数据时差距就出来了。元组在内存占用和读写速度上通常都比列表更优原因在于列表为了支持频繁增删会预分配一部分空闲内存还要维护动态扩容的状态元组是固定结构创建时是多少就是多少没有任何额外开销。一个直观的实验import sys t tuple(range(10000)) l list(range(10000)) print(sys.getsizeof(t)) print(sys.getsizeof(l))在我的测试环境里同样存放 0 到 9999 的整数元组的内存占用大致在 80056 字节列表则超过 87616 字节。数据量越大差距越明显。创建和读取方面元组同样更轻快因为内部操作更简单。但这不意味着元组在所有场景都碾压列表。如果你的数据确实需要动态增删元组就没有任何优势它根本做不了。选择原则其实很简单这里直接给出一张决策表数据处理方式推荐类型关键原因结构固定创建后不再修改元组不可变可哈希更安全做字典键或集合元素元组满足可哈希要求函数需要返回多个结果元组自动打包接收方不可误改需要频繁增删元素列表元组做不到需要按位置修改已有元素列表元组做不到大数据量反复遍历、读取元组内存占用更小访问更快在函数间传递且不希望被改动元组防御性编程我自己在实际编码中的习惯是先确认数据的“生命周期”。这个数据创建之后会不会被追加内容会不会被替换元素如果有任何一个答案是“会”那就用列表如果所有答案都是“不会”那我优先用元组。这样想一次很多选择上的纠结就消失了。还有一些框架层面的经验。比如配置项、常量组一类的数据我会全部声明为元组因为它虽然不会变但可能被多处引用万一某个地方手滑写了个append用列表时可能整个程序都被带跑偏用元组直接在报错阶段就把问题拦下来了。再比如存储坐标、RGB 颜色、固定的用户信息字段元组都是比列表更贴合语义的选择。最后再补充一个看代码的小窍门在一个项目里看到括号串加逗号第一反应就是元组看到方括号那才是列表。这个直觉在你快速阅读陌生代码时非常管用尤其是在拆解那些把多返回值、解包、嵌套揉在一起的表达式时能省下不少脑力。回到最开始那个报错。TypeError: tuple object does not support item assignment表面上是一句“不能改”的提示实际上是在提醒你这条数据被设计成只读的别去破坏它的结构。我在实际项目里遇到过不止一次正是因为元组这个“不让改”的设定才挡住了很多本可能悄悄发生的数据篡改问题。多写几年代码回头看这种“限制”反而是 Python 里最让人安心的一类设计。
阅读完成 · 觉得有帮助？
