Python JIT开发遭官方紧急叫停:六个月内重新补PEP,否则将彻底移除主干代码!

Python 社区正在经历一次不太常见的“内部刹车”事件。

近日，Python 指导委员会突然发布了一则《关于 JIT 项目》的公告，要求暂停代码主分支上即时编译器（JIT）项目的全部新功能开发工作。现有的代码可以继续修 Bug、进行安全更新， 而所有新功能、新优化、性能迭代全部暂停。

该委员会还给出了明确的时间限制：未来 6 个月内，负责 JIT 开发的核心开发者以及贡献者必须提交一份正式的 PEP 提案；若逾期未落地，JIT 代码将彻底从主分支中删除。

这份公告一出，让很多开发者感到意外，毕竟 CPython 中正在推进的 JIT 编译器项目，本来是 Python 3.13/3.15 性能路线的重要组成部分，甚至已经带来了约 8–9% 的几何平均性能提升（x86-64 Linux），怎么说停就停了？

从“实验功能”到“治理争议”

事实上，Python 内置 JIT 是近年核心性能优化重点，也如上文所说，已实现实打实的性能提升。

然而，Python 的 JIT 并不是一开始就作为正式特性设计的。

它起初是以“实验性质”进入 CPython 主分支，对应的 PEP 是 PEP 744，但这只是一个 Informational PEP（信息性提案），并没有完成标准功能所需的完整治理闭环。

此外，这个 PEP 本身也明确留了一堆“未解决问题”，包括是否有长期维护团队、安全性审查、调试与工具链支持、对发行版和下游的影响、运行时保证边界等关键问题，多年来始终没有形成统一社区规范。

Python 指导委员会成员 Pablo Galindo Salgado 发文也承认此前监管宽松，放任高复杂度的核心功能长期处于非正式实验状态。其表示：“对于如此复杂、影响范围如此广的变更，我们（指导委员会）在流程执行上的把控不够严格。”

预留六个月时间，让 JIT 核心开发者们重新撰写 PEP

为此，Python 指导委员会成员要求 JIT 编译器的核心开发者和贡献者们重新撰写正式 PEP，明确 JIT 的官方定位、维护机制、生态影响与兼容标准，供社区讨论，指导委员会在评估后正式接受或者拒绝。

同时 Python 委员会也建议 JIT 编译器的核心开发者开放新思路：不要局限现有单一 JIT 方案，可搭建通用 JIT 基础设施，支持多种优化策略迭代测试。

此外官方明确最新版本的 PEP 提案至少能解决以下几个问题：

• 尤其对于这样规模和复杂度的子系统而言，维护确实是一个现实问题。因此，这份 PEP 应当明确说明：JIT 将如何在长期内得到持续支持与维护，以及它会如何影响那些并不直接参与 JIT 开发的维护者和贡献者。

• 它还需要说明，JIT 将如何与现有 CPython 特性和工具保持兼容。例如，JIT 如何与 CPython 已有能力协同工作，并且对这些能力提供什么样的保证。这包括诸如 free-threading、性能分析器以及调试器等，但 PEP 应该以更广泛、更细致的方式来处理这些问题，而不是简单地当作一个固定检查清单。

• 此外，还需要给出清晰、可衡量的成功指标与时间规划。也就是说，这个项目到底要达成什么目标、在什么时候达成，例如性能目标、平台覆盖范围以及内存开销等方面的具体指标。

• 另一个重要问题是它与其他 JIT 编译器的关系。需要说明该设计是否旨在提供一种通用基础设施，以供其他项目在其之上构建；以及它预期是与第三方 JIT 实现兼容还是不兼容，例如 CinderX、Numba、PyTorch 或其他任何第三方 JIT。

• 还需要明确当前 JIT 架构是否被视为稳定设计，还是仍然可能继续发生变化。

不止于此，Pablo Galindo Salgado 进一步表示，「以上列表并不完整，它只是我们希望该 PEP 能覆盖的问题类型示意。随着社区讨论的推进，我们也预期会进一步补充新的关注点。」

社区争议：核心开发者反对冻结，赞同声也此起彼伏

面对这一政策变更，Python 社区出现了明显的分歧。

据外媒 The Register 报道，JIT 核心开发者 Mark Shannon 认为：“在新 PEP 获批前叫停所有开发，让我们进退两难。” 

因为这会迫使 JIT 团队仓促制定新提案，却不给社区留出充分的讨论时间。他透露，团队原本计划今年晚些时候再推出新提案，届时编译器的性能提升效果会更显著。

另外，Mark Shannon 已申请一两个月的宽限期，以便继续推进开发。他表示：“开发暂停可能导致项目失去推进动力，还会流失我们近期吸纳的新贡献者。” 

当被问及能否在分支仓库中继续开发时，Mark Shannon 称此举并不可行 —— 由于优化代码的生成机制特殊，分支与主分支的代码差异会极大，难以维护管理。

另一边，也有一些开发者认为  Python 委员会的决定是合理的：JIT 已经不是“小实验”，如果未来要成为 CPython 核心组件，必须走标准 PEP，否则会破坏 Python 一贯的“治理一致性”。

结语

本次整改意味着 Python 官方彻底收紧主干分支实验性功能规则，终结了 JIT 多年“边做边试、无正式规范”的迭代模式，核心功能升级全面回归标准化社区共识机制。

Python 委员会成员 Pablo Galindo Salgado 也解释道，「我们并非要终止这个项目，而是要让项目本身以及社区获得清晰的说明和明确的承诺，以应对 CPython 运行时如此重大的变革。」

不过，现实来看，指导委员会的这一决定，也让 JIT 项目的前景蒙上阴影。此前该项目几乎确定会成为 CPython 的官方组成部分，而如今变数陡增。要在六个月内完成一份 PEP 提案并达成共识，时间本就十分紧张；一旦 JIT 代码真的被移出主分支，项目发展节奏大幅放缓。

对此，你怎么看？

参考：

https://www.theregister.com/devops/2026/06/08/python-jit-compiler-may-be-removed/5252079

https://discuss.python.org/t/an-announcement-from-the-steering-council-regarding-the-jit-project/107638

推荐阅读：