Python 的内部实现如何成为接口的一部分

Python 的 a + b 看起来很简单，但解释器要怎样才能让它适用于数字、字符串和用户定义的对象？在这场 2016 年的演讲中，Flask 创建者 Armin Ronacher 认为，CPython 的内部决定已经足够可见，以至于程序会依赖它们。这种可见性给了开发者很大的能力，也增加了修改解释器的成本。以下例子描述的是他当时讨论的 Python 实现，并非当前内部机制的规范。

常见解释会说 a + b 等价于 a.__add__(b)。Ronacher 沿着他讨论的 CPython 实现追踪这个运算符：字节码到达加法操作后，会先为精确的整数和字符串类型走快速路径，再进行通用数字处理，必要时还会处理序列拼接。PyNumber_Add 虽然名字里有 Number，也参与序列相加。操作数的类型及其关系会影响分派。直接查找特殊方法走的是另一条路径；他说，某些情况下后者甚至更快，但并非总是如此。观看加法路径讲解。

06:40查看原图

这里的类型槽位是 C 类型结构中保存操作函数指针的位置，例如数字加法槽位；它不同于 Python 用来管理实例属性的 __slots__。对象指向其类型，解释器可以利用类型的槽位执行操作。因此，熟悉的简写适合入门，却不能完整描述实现。

Ronacher 回顾说，内置 C 类型和 Python 类最初是两套机制，同时也承认自己不确定确切的历史顺序。C 类型提供操作槽位，Python 类提供 __add__ 等特殊方法。解释器在两者之间搭桥：包装器把 C 槽位暴露为 Python 可见的方法，又把 Python 定义的特殊方法连接回类型槽位。数字加法与序列拼接使用不同的槽位，使这种对应关系比单个方法名暗示的更复杂。

12:30查看原图

这不仅是实现图中的细节：扩展开发者使用 C API，Python 程序也能观察到槽位包装器。Python 定义的函数与 C 槽位包装器是外观不同的对象。Ronacher 还提到描述符绑定：Python 方法可能把实例作为 self 绑定，而 conversion = int 这样的类属性则依赖 int 不以这种方式绑定。代码可能依赖这些差异，因此其他实现也必须复现原本看似偶然的行为。观看类型槽位讲解。

一个历史例子是编译后的 re 对象：其 C 实现可以支持某些操作，但普通 Python 属性访问却不能获得 __class__ 和 __repr__ 等预期属性。Ronacher 说，这个例子到 Python 2.7 时已经修复。它说明的是旧 C API 的问题，并不是让读者在今天复现该行为的方法。

22:30查看原图

他还描述了一个 Python 2 旧式类代理：它把属性访问转发给底层值，特殊操作也可以通过这种方式转发；新式类查找特殊方法的方式不同。这些例子说明，用更整齐的模型替换原有机制可能改变可观察的行为，也说明 PyPy 等其他实现需要处理的不只是教程中的简化解释。观看示例。

24:10查看原图

早期字节字符串让程序员习惯直接访问字符串中的位置。Ronacher 描述说，Unicode 支持继承了这种预期，而字符所需的数值范围变大了。在他的 Python 2 例子中，窄构建可能把一个 emoji 暴露为两个代理单元；宽构建则每个单元使用四字节。UTF-8 使用变长编码，对常见文本可以节省空间，但定位任意字符位置比按固定宽度跨越单元需要更多工作。

他说，他讨论的 Python 3 实现会根据字符串中最大的字符选择存储宽度。他对 Unicode 历史和效率的说法是用于教学的简化；按码点索引也不一定等于选取用户感知的一个字符。更普遍的问题是：当实现行为变成使用者的预期后，它会持续影响后续设计。观看 Unicode 讨论。

暴露内部状态也有价值。调用帧代表一次正在执行的调用，提供与其执行相关的信息。Ronacher 描述了如何用 sys._getframe 检查调用位置的状态，包括局部变量、文件名和异常信息；在某些情况下还可以修改局部变量。他认为，大量代码使用这一能力，促使实现即使付出成本也要支持它。

35:50查看原图

他的例子包括检查调用者的接口机制、把警告归到上几层调用位置的功能，以及显示调用者而非日志辅助函数位置的日志记录。他还描述了向运行中的解释器附加调试器，以及 Sentry、Django 和 Flask 如何利用回溯与局部状态。这些是访问能力能支持的工具，并不意味着每个部署环境都允许实时调试。观看调用帧示例。

sys.modules 暴露了一个按名称保存已导入模块的缓存。这让已加载模块可以被发现：代码能按名称找到模块及其中的类。Ronacher 提到 pickle、复制机制和自定义导入代码都会使用这种共享状态。Pickle 用于序列化 Python 对象，而持久保存的数据可能让这些依赖延续很长时间。

在他描述的系统里，以同一个名称加载某个库的两个版本很困难，因为使用方期望该名称指向某个缓存模块。如果在查找中加入版本或作用域，就会改变代码和已保存数据中的既有假设。这是他对当时兼容性问题的分析，并非声称今天所有隔离或多版本加载方式都不可能。观看导入机制讨论。

Ronacher 描述了当时 CPython 的一种设计：内置静态类型对象位于全局地址。检查对象是否恰好属于整数类型时，可以将其类型指针与内置整数类型的地址比较。这些共享对象还有可变的引用计数。他尝试让多个独立解释器分别运行于不同线程时，遇到了对这些对象及已暴露的 C 层引用计数的依赖。

41:40查看原图

他把这些约束与改变全局解释器锁（GIL）和隔离解释器的困难联系起来，同时指出，即便存在性能和并发限制，日常 Python 工作仍然可行。这是他在 2016 年的判断和经验，不是对当前 GIL、子解释器或 Python 构建版本的能力保证。观看隔离问题讨论。

在观众问答中，一位听众建议使用较窄的公共 API。Ronacher 同意这样可能更容易演进，同时承认开发者会失去一些他所看重的内省能力。被问到特殊处理是否是性能所需时，他提出，更简单、更小的高频执行路径可能改善缓存局部性和分支预测，也可能让不常见的情况更快。这是他在讨论中提出的设计假设，演讲没有用基准测试证明它。

理解接口边界需要同时看两面：暴露内部细节能支持哪些有用工具？使用者又可能开始依赖哪些可观察细节？这是一项取舍，而不是否定内省或兼容性中任何一方的理由。观看问答。