Python 的实验性即时编译器（JIT）正面临被移除的命运。该功能于 2024 年随 Python 3.13 版本加入 CPython，但今年 6 月，Python 指导委员会宣布暂停主分支中的 JIT 开发工作，直至通过一项已接受的 Python 增强提案（PEP）来解决维护、兼容性担忧，并设定明确的成功指标及完成时间表。
尽管后续产生了 PEP 836（名为“JIT Go Brrr: CPython 支持的 JIT 编译器之路”），旨在满足理事会要求，但在经过数月讨论后，JIT 维护者最终撤回了该提案。这一曾经备受期待的项目目前看来已走向终结。
JIT 功能的引入与争议
联合开发团队于 2024 年初由 Brandt Bucher 加入 CPython。通常情况下，此类主要功能需在理事会批准标准轨道 PEP 后方可合并。Bucher 在 Python 核心开发者冲刺活动中发表了关于 JIT 的演讲，并宣布计划合并该功能，但他并未遵循创建或提交 PEP 以获得批准的常规流程。此举促使指导委员会成员、同时也是 Python 3.13 发布经理的 Thomas Wouters 介入并要求其补全程序。
Bucher 和 Savannah Ostrowski 随后起草了 PEP 744（“JIT 汇编”）。这是一份信息性 PEP，仅向社区提供信息，并不代表继续推进该功能的正式共识。LWN 曾在 2024 年 4 月报道过相关讨论，以及 Bucher 在 PyCon US 2024 和 PyCon US 2025 上的后续演讲。
理事会的最后期限
在今年 6 月之前，JIT 的工作一直基于 PEP 744 进行。当时，指导委员会正式要求 JIT 维护者创建一个标准轨道 PEP。虽然部分开发者如 Antoine Pitrou 对理事会突然介入表示疑惑，但 Wouters 指出，理事会已就此话题讨论许久，旨在确保 JIT 工作不会干扰其他项目。委员会选择等待 Python 3.15 测试版发布后再行动。
理事会要求提交的 PEP 需为 JIT 的存在提供理由，并为提交和接受该提案设定了六个月的最后期限。若未能按时达成，理事会将要求从 CPython 主分支中删除 JIT 代码。
Bucher、Ostrowski 和 Ken Jin 于 7 月 3 日在 Python 论坛上发布了 PEP 836 草案以供社区反馈。该提案引发了广泛讨论，既有支持声音，也有批评意见。关键评论包括 Wouters 和 Mark Shannon 的观点。Shannon 认为 PEP 应仅涵盖接受 JIT 工作的目标，而不应包含实施细节；此外，许多社区成员要求提供更多额外信息。
Ostrowski 为 PEP 的结构进行了辩护，但 Bucher 对此持保留态度。截至 9 月的讨论显示，关于 PEP 的对话速度放缓，且没有承诺制定新的 PEP。
实验性质的核心问题
9 月 21 日，Wouters 发布了指导委员会声明（除 Ostrowski 外，她是现任指导委员会成员）。声明指出，虽然 PEP 回答了理事会提出的大部分问题，但委员会关注的重点并非 JIT 是否应成为受支持的功能，而是它是否应继续作为 CPython 主分支中的实验存在。
允许实验的主要问题是缺乏统一的设计，以及核心开发人员、包维护者和用户在实验改变行为和 API 表面时所面临的不确定性。
委员会认为，PEP 对于支持计划和性能标准的描述不够具体，而在其他领域则显得过于模糊或乐观。声明列出了理事会期望解决的十点清单，涉及从内存影响到安全性的多个方面。例如，在平台兼容性问题上，理事会希望确保 JIT 设计易于新平台采用，且不依赖特定平台知识即可维护。
在用户影响方面，理事会指出 PEP 未充分说明启用 JIT 后用户可见的差异。鉴于许多用户依赖解释器设计的确定性，理事会要求澄清如何处理这些差异，以及在不可避免的行为变化下应采取何种措施。
安全性也是关注焦点之一。理事会建议与 Python 安全响应团队进行讨论，并将安全审查纳入支持状态的标准之中。
PEP 836 指定了一个兼容性审查里程碑，对应第一个 Python 3.17 版本候选，预计于 2028 年 8 月左右发布。该阶段将运行顶级 PyPI 包的测试套件，以验证 JIT 是否导致破坏。然而，理事会希望大幅提前这一时间表。
委员会还担心 JIT 设计中存在缺失环节，并希望就这些话题展开更多讨论。Bucher 在几天后回复感谢理事会的详细反馈，并表示团队将根据建议开展工作。
撤回与未来展望
经过考量，PEP 作者决定不再追求理事会的批准。10 月 19 日，Ostrowski（同时担任 Python 3.16 和 3.17 的发布经理）宣布 PEP 将被撤回：
董事会对这项提案的要求很高，我们不认为我们有能力推进目前的版本。我们继续相信 PEP 中概述的技术方向，包括自由线程支持和基于方法的前端，并对 CPython 中 JIT 的潜力保持乐观。我们将提供参考实现，并将其与已撤回的 PEP 联系起来。
Barry Scott 询问这是否意味着 JIT 工作停止。Brett Cannon 回应称，主要仓库中的工作将停止，但是否在其他地方继续取决于社区。Mark Graham 建议在理事会最后期限前提交替代 PEP 仍有可能，但 Cannon 认为这不太可能。
随着 PEP 的撤回，JIT 代码很可能很快从 CPython 主分支中移除，以便在 Python 3.16 开发周期早期解决由此产生的任何问题。目前尚不清楚原始驱动者是否打算继续相关工作。媒体已向 PEP 作者发送电子邮件寻求澄清，但尚未收到回复。
