10 月 19 日，Python 官方讨论区里，PEP 836 的作者之一 Savannah Ostrowski 发了一条帖子，宣布撤回这份提案。她写道，委员会给这么大的提案设高门槛是对的，只是他们“没有足够的个人精力”（we don't feel we have the personal bandwidth）把现在这一版继续推下去。

这条帖子分量很重。按 Python 指导委员会今年 6 月定下的规矩，CPython 里那个实验了两年多的 JIT 编译器，要是在六个月内拿不出一份被接受的标准 PEP，就得从主线删掉。期限是 12 月 5 日。PEP 撤了，眼下也没人说要另起一份，JIT 这次大概率真要被拆出去。

更热闹的是后面。10 月底，讨论区里开始有人说“是指导委员会杀了 JIT”，委员会成员 Pablo Galindo Salgado 直接回了一句：“说这是委员会的决定，根本就是错的。”

一个让 Python 变快的项目，做了六年，最后落到这一步。下面从头捋一遍。

JIT 和“复制再打补丁”

我们平时用的 Python，官方实现叫 CPython，是一个用 C 写的解释器。你的 .py 文件会先被编译成字节码，也就是一串像 LOAD_FAST、BINARY_OP 这样的小指令；解释器再一条一条读这些指令，每读一条就跳到对应的 C 代码去执行。

这个“读一条、跳一次”的动作叫分派，本身就有开销。一个热循环跑一百万次，这份开销就付一百万次。

JIT（Just-In-Time，即时编译）的思路是：程序跑起来以后，发现哪段代码特别热，就当场把它翻译成机器码，下次直接跑机器码，不再一条条解释。Java 的 HotSpot、JavaScript 的 V8、Python 圈里的 PyPy，靠的都是这一手。

CPython 选的是一种叫 copy-and-patch（复制再打补丁）的做法，来自一篇公开的学术论文。它在构建 Python 的时候，就用 LLVM（一套常见的编译器工具链）把每条微指令预先编译成机器码“模板”，模板里留着空位；运行时遇到热代码，把对应模板复制进内存，往空位里填上具体的地址和常量，拼成一段连续的机器码。

这种做法的好处是便宜。按 PEP 744 的说法，整套 JIT 只要大约 900 行构建期的 Python 和 500 行运行期的 C；而且模板和解释器用的是同一份指令定义，改了字节码，JIT 后端“白送”跟着更新。

听上去很美。问题出在“快多少”上。

一个五倍的承诺

故事要从 2020 年 10 月说起。CPython 核心开发者 Mark Shannon 公开了一份计划：分四个版本，把 CPython 提速 5 倍。每个版本大约快 50%，1.5 的四次方差不多就是 5。前两个阶段靠优化解释器，后两个阶段要上 JIT。

那年年底，Python 之父 Guido van Rossum 加入了微软。2021 年 5 月的 Python 语言峰会上，他宣布微软出钱组了一个小团队来做这件事，成员有他自己、Mark Shannon 和 Eric Snow，第一个目标是让 3.11 快一倍。这就是后来大家熟悉的 Faster CPython 项目。

第一阶段交得不错。2022 年发布的 Python 3.11 引入了“自适应特化解释器”（PEP 659）：解释器会观察每条指令实际遇到的数据类型，把通用指令换成专门处理整数、字符串的快速版本。官方文档写的是，在标准测试集上平均提速 1.25 倍。

3.12 又把所有字节码的定义集中写进一个 DSL 文件（一种专门描述指令的小语言）。这一步看着不起眼，后来的 JIT 正是建在它上面。

JIT 进了主线，但一直不够快

copy-and-patch JIT 最早是 Brandt Bucher 在 2023 年 10 月的 CPython 核心开发者冲刺会上展示的，同年圣诞节提了 PR，2024 年初合进 main。从 3.13 开始，你可以在编译 Python 时手动打开它，但它一直挂着“实验性”的牌子。

2024 年 4 月，Bucher 和 Ostrowski 写了 PEP 744，说清楚这块牌子什么时候能摘：JIT 要在性能上有实打实的好处，量级“大约 5%”；在那之前不该用于生产，而且“随时可能被移除”。

结果这道 5% 的门槛迟迟没跨过去。后来的 PEP 836 自己承认，最初那套简单的追踪方式，“在 3.13 和 3.14 里一开始没有带来任何提速”。

直到 2026 年 10 月刚发布的 3.15，情况才有了起色。PEP 836 给的数据是：用标准的 pyperformance 测试集、取几何平均，3.15 的 JIT 比解释器快 4% 到 12%，看机器而定。附录里列了几台 Tier 1 机器在 6 月中下旬的结果：苹果 M3 Pro 快 12.6%，Ampere 的 192 核服务器 7.3%，Intel i5-8400 是 6.9%，AMD Ryzen 5 3600X 只有 4.7%。

社区有个专门盯 JIT 性能的网站，名字就叫 doesjitgobrrr.com（“JIT 跑得飞快吗”）。看它最近 30 天的曲线，大部分机器稳在 5% 目标线以下，也就是比解释器快；树莓派 5 那条线则一直在 0 附近晃。

doesjitgobrrr.com 截图：JIT 相对解释器的耗时变化，越往下越快；虚线是 5% 目标

4% 到 12%，放在任何一个成熟项目里都算不错的成绩。可它离当初说好的“五倍”太远了，就连 JIT 自己定的 20% 目标也还差一截。

金主走了

就在 JIT 慢慢爬坡的时候，钱先没了。

2025 年 5 月，Python 核心开发者 Brett Cannon 在 Fosstodon 上说，微软裁掉了三位 CPython 核心开发者：Eric Snow、Irit Katriel 和 Mark Shannon。Faster CPython 团队的 Mike Droettboom 随后确认：“微软对 Faster CPython 项目的支持昨天被取消了”，团队大部分人被裁。The Register 等媒体也做了报道。

这个团队留下的成绩其实不差。JIT 作者之一 Ken Jin 在讨论区里算过，3.14 大约比 3.10 快 20% 到 40%。只是“五倍”那一章，JIT 担纲的后两个阶段，再也没有一家公司专门养人来写了。

委员会要一份 PEP

2026 年 6 月 5 日，Python 指导委员会通过 Pablo Galindo Salgado 发了一份公告。指导委员会（Steering Council，简称 SC）是 Guido 卸任“终身仁慈独裁者”之后，由核心开发者选出来做最终决策的五人小组。

指导委员会 6 月 5 日公告节选：PEP 被接受前不在 main 上做新的 JIT 开发；六个月后仍没有，代码移出主线

公告的意思很直接：JIT 已经在主线里待了两年多，影响面越来越大，需要一份正式的标准 PEP 来说清楚。PEP 被接受之前，main 分支上不再做新的 JIT 开发，只修 bug 和安全问题。如果六个月内没有被接受的 PEP，JIT 代码“必须从主线移除”。

委员会还列了一串要回答的问题：谁来长期维护？和自由线程（free-threading，去掉 GIL 的那个模式）、性能分析器、调试器怎么兼容？有没有可量化的指标和时间表？和 CinderX、Numba、PyTorch 这些外部 JIT 什么关系？架构什么时候能稳定下来？

Pablo 补了一句，委员会“会保持灵活”。但 Mark Shannon 当时就提出了担心：暂停开发“有失去势头、失去新贡献者的风险”；让志愿者去分叉仓库里接着干，“对志愿者来说并不现实”。

JIT Go Brrr

7 月初，Ostrowski、Ken Jin 和 Bucher 交出了 PEP 836，标题起得很皮：「JIT Go Brrr」。

它给出了一个具体目标：到 3.17 beta 1，“JIT + 自由线程”要比“只开自由线程的解释器”快至少 20%。第一年先做三件事：换成基于方法的前端、支持自由线程、在带 GIL 的普通模式下做到至少 5%。

PEP 也交代了现状。官方发布的 Windows 和 macOS 安装包里其实已经带着 JIT，只是默认关着，设置环境变量 PYTHON_JIT=1 才会打开；Fedora 和 Gentoo 的打包方式也一样。代价是构建 Python 时需要 LLVM。

资金那一节写得很坦白：项目“最初的主要企业赞助方已经结束了专项资助”，现在靠志愿者，加上 Arm、FastAPI Labs 和 OpenAI 的支持。

9 月 21 日，委员会成员 Thomas Wouters 给了反馈：PEP 回答了所有问题，但长期支持和性能标准都写得比较含糊；而且 pyperformance 这套测试有可能低估真实场景，换句话说，跑分好看不等于大家的程序真的变快。

撤回

一个月后，作者们决定不改了。

PEP 836 页面现在的状态：Withdrawn（已撤回），决议日期 2026-10-19

Ostrowski 在 10 月 19 日的帖子里说，他们仍然看好 PEP 里的技术方向，包括支持自由线程和基于方法的前端，只是没有足够的个人精力继续推进；参考实现会公开出来，链接挂在撤回的 PEP 上，谁有兴趣都可以接着做。有人问 JIT 的工作是不是停了，Brett Cannon 答：“在 CPython 仓库里，是的。”PEP 撤回，就意味着代码“会被移出去，放到别处”。也有人提醒，12 月 5 日之前理论上还能有人另交一份 PEP；Cannon 认为不太现实，因为正在推动 JIT 的人基本都是这份 PEP 的作者或贡献者，而撤回的决定正是他们在核心开发者冲刺会上一起做的。

10 月 27 日，InfoWorld 用了一个双关标题报道这件事：Python jettisons the native JIT（Python 抛弃了原生 JIT），后面跟着半句“至少暂时如此”。

到底是谁“杀”了 JIT

真正吵起来是 10 月 29 日以后。

有用户在讨论区引述圈子里的“风声”，说是委员会把 JIT 弄死的。核心开发者 Łukasz Langa 先站出来反驳这种指责。Pablo 随后写得更重：“委员会没有杀死 JIT，也没有拒绝 PEP 836。我们对它根本没做任何决定，因为这份 PEP 从来没有提交给我们裁决。”他解释，9 月那份反馈是作者们请委员会提前公开给的，为的是缩短来回、把立场摆明。他的结论是：“把它说成委员会的决定，根本就是错的。”

Ostrowski 的身份有点特殊：她既是 PEP 作者，也是指导委员会成员，按规矩要回避对这份 PEP 的裁决。她出来说，委员会在 PEP 撤回后没有再做任何决定，也没有想绕着弯拆掉 JIT，“背后没有别的动机”，只是“我们的精力状况变了”。

老牌核心开发者 Nick Coghlan 给了一个更冷静的解读：这更像是“一个资助决定走到了它自然的结局”。JIT 起步时有好几个人全职做 CPython 性能，钱撤了以后，主力们现在给出了答案：没有专项资助，他们认为这块维护不下来。他还补了一句：JIT 开发有大量枯燥的测试和兼容工作，当成拿工资的工作可以，当成志愿活动就很难熬。

Pablo 在同一条回复里也解释了委员会为什么非要一份 PEP。他列了一串这几年的设计变动：3.12 上了微指令和字节码 DSL，3.13 加了追踪和 copy-and-patch，3.14 又重构了一轮解释器，3.15 重写成追踪记录，现在又提议换成基于方法的前端。每一步都伸进了所有核心开发者、工具作者和发行版都依赖的解释器，却没有一步走过 PEP；而按 PEP 836 自己的说法，前两轮连提速都没有。对一个要被全世界几百万台机器跑的解释器来说，委员会想要一份白纸黑字的路线图，也说得过去。

还有一个声音值得听。Brandt Bucher 说，期限还没到，JIT 也还没真被删，现在就写“事后复盘”有点不合适。

所以这事很难找出一个反派。钱没了，人累了，设计还在变，规矩要求落到纸上，几件事撞在同一年。

默认就没开

对绝大多数写 Python 的人来说，几乎没有影响。JIT 默认一直是关的，你不手动设 PYTHON_JIT=1，用的就是解释器。既然默认不开，3.10 到 3.14 那 20% 到 40% 的提速自然也不是 JIT 给的，不会因为拆 JIT 消失。

受影响的是两类人：一类是已经在生产里打开 JIT 吃那 4% 到 12% 的人；另一类是指望 Python 有朝一日像 JavaScript 一样靠 JIT 大幅提速的人。前者之后大概要另找办法，后者恐怕得再等等。PEP 744 当初那句“随时可能被移除”，现在兑现了。

代码不会凭空消失。参考实现还在，作者们也没说永远不做，只是不再在 CPython 主线里做。Python 要变快，接下来大概还是靠解释器一点点抠，或者交给 PyPy、Numba、CinderX 这些外部方案。

更多相关技术内容咨询欢迎前往并持续关注好学星城论坛了解详情。

想高效系统的学习Python编程语言，推荐大家关注一个微信公众号：Python编程学习圈。每天分享行业资讯、技术干货供大家阅读，关注即可免费领取整套Python入门到进阶的学习资料以及教程，感兴趣的小伙伴赶紧行动起来吧。