在 Python 的对象模型中，大量语言行为——函数调用、属性访问、运算符运算、迭代、上下文管理等——并不是通过“按名称查找某个方法”来完成的，而是由解释器在类型层面触发的一组固定分派入口完成的。
在 CPython 的实现中，这些入口被称为“类型槽位”（type slots）。
理解类型槽位，是将“协议”这一语义概念落实到运行机制层面的关键一步。
一、为什么需要理解类型槽位
在语言层面，我们常说：
• 实现 __iter__ 就支持迭代
• 实现 __call__ 就可以被调用
• 实现 __add__ 就支持加法
• 实现 __get__ 就成为描述符
这些说法在语义层面是正确的，但仍然停留在“方法名层面”。
真正的问题是：解释器如何知道在某个语境中应该调用哪一个行为？
答案并不是“简单地通过属性查找判断对象是否存在某个同名方法”，而是解释器通过类型对象的槽位表进行分派。
例如：
调用行为 → tp_call迭代行为 → tp_iter / tp_iternext属性访问 → tp_getattro...
这些槽位在类型对象中以固定字段形式存在，槽位中保存的是函数指针（通常为 CPython 的 slot wrapper，用于桥接到 Python 层定义的特殊方法实现）。
当解释器遇到某种语法语境时，例如函数调用、运算符运算或 for 循环，它并不是去查找方法名字符串，而是根据语境直接读取对应槽位，并调用其中的函数指针。
类型槽位并不是替代特殊方法，而是特殊方法在运行期的承载结构。
• 用户在类字典中定义特殊方法
• 类型构造阶段将其映射到槽位
• 解释器在语法语境中调用槽位
• 槽位再回调到用户定义的方法
因此，特殊方法是语言接口，槽位是运行分派机制。二者构成一体两面的结构。
二、类型对象与槽位结构
在 Python 中，类本身也是对象。
当执行：
class A: def f(self): pass
解释器会创建一个类对象（type object）。
在 CPython 实现中，该对象在底层对应一个 PyTypeObject 结构。这个结构除了包含类名、继承关系、属性字典等信息外，还包含大量函数指针字段，即所谓的“类型槽位”。
可以从概念上理解为：
类型对象 = 元信息 + 属性字典 + 行为槽位表
需要强调的是：
• 类型槽位不是类字典中的条目
• 槽位是类型对象的内部结构的一部分
• 类字典中的特殊方法在类创建或更新时会映射到对应槽位
三、特殊方法名与槽位的映射
在 Python 语法层面，我们定义的是特殊方法名，例如：
但在类型层面，解释器真正使用的是对应的槽位。
常见映射关系（CPython 实现）如下：
| |
|---|
__iter__ | tp_iter |
__next__ | tp_iternext |
__call__ | tp_call |
__getattribute__ | tp_getattro |
__add__ | tp_as_number->nb_add |
__getitem__ | tp_as_mapping->mp_subscript 或 tp_as_sequence->sq_item |
__get__ | tp_descr_get |
当类对象创建完成（type.__new__ 执行完毕）时：
1、解释器扫描类字典
2、如果发现特殊方法名（如 __iter__），则将其与对应槽位（如 tp_iter）建立映射
3、在类型对象中填充相应槽位
此后，当解释器遇到特定语法语境时，会直接使用槽位进行分派，而不是按方法名查找。
下面以迭代行为为例来描述槽位分派过程。
当执行：
语义上等价于：
但 iter(obj) 并不是简单执行：
解释器在内部会：
1、取得 type(obj)；
2、检查该类型是否提供迭代入口（在 CPython 中表现为 tp_iter 槽位是否已填充）；
3、若存在，则通过该槽位调用对应实现，获得一个迭代器对象；
4、若不存在，则进入序列回退路径（尝试基于 __getitem__ 建立迭代规则）。
因此，迭代行为的成立依赖于类型对象的结构状态，而不是实例属性中是否存在名为 __iter__ 的方法。
四、类型槽位如何决定协议成立
可以给出一个统一判断：协议是否成立，取决于对应槽位是否被填充，而不是对象是否“拥有某个方法名”。
1、迭代协议
当执行：
解释器：
• 检查 type(obj).tp_iter
• 若存在，则调用该槽位
• 若不存在，则尝试序列回退路径
2、可调用协议
当执行：
解释器：
• 检查 type(obj).tp_call
• 若槽位存在，则调用
函数对象、类对象以及实现 __call__ 的实例之所以可调用，是因为其类型填充了 tp_call。
3、运算符协议
当执行：
解释器：
• 检查 type(a).tp_as_number
• 在其子结构中调用对应的加法槽位（nb_add）
而不是简单执行：
4、描述符协议
当访问：
解释器：
• 通过 tp_getattro 进入属性访问流程
• 在类字典中查找属性
• 若属性对象的类型填充了 tp_descr_get，则触发描述符分派
因此，描述符成立的条件是其类型实现了描述符槽位，而不是仅仅存在 __get__ 名称。
五、为什么实例字典无法改变协议
考虑以下代码：
class A: passa = A()a.__iter__ = lambda: iter([1, 2, 3])iter(a) # TypeError
这段代码会抛出 TypeError。
原因是：
• 协议分派发生在类型层，即检查的是 type(a) 的 tp_iter
• 实例字典中的 __iter__ 修改不会更新类型槽位
此时 tp_iter 槽位仍然为空，因此协议未成立。
这揭示一个核心原则：协议分派是类型级机制，而不是实例级属性查找。
六、类属性修改与槽位更新
当通过类对象赋值：
class A: passdef f(self): return iter([1, 2, 3])A.__iter__ = f
在 CPython 中：
• type.__setattr__ 会触发槽位重新计算
• 对应槽位会被重新填充
因此：
可以成功。
这说明，槽位更新由类型对象管理，而不是字典本身自动完成。
七、类型槽位的统一理解
从对象模型角度总结：
• 类型对象内部维护一组固定行为入口（槽位）
• 特殊方法名是语言层对槽位的映射接口
• 协议成立取决于该类型在其 MRO 合成后的类型结构中是否为该槽位提供实现（是否非空）
• 解释器在特定语境下直接调用槽位，而非方法名查找
• 实例属性不会改变协议
• 类属性更新可能触发槽位更新
因此，对象“支持某种语义”，并不是因为它“拥有某个方法名”，而是因为其类型结构在创建或更新时填充了对应的槽位。
📘 小结
类型槽位是 Python 协议机制在 CPython 实现中的结构基础。解释器在特定语法语境中，并不是通过方法名查找来决定行为，而是通过类型对象中预定义的槽位进行分派。特殊方法名只是语言层对这些槽位的映射接口。
理解类型槽位，有助于从结构层面把握协议成立的真正条件，并澄清“方法名”与“行为分派”之间的本质区别。
