Python 指导委员会要求 JIT 项目暂停开发，需提交正式 PEP

Python 指导委员会关于 JIT 项目的公告

我们想花点时间谈谈 CPython 中的实验性即时编译器（JIT），以及我们认为它应该走向何方。

过去几年，几位核心开发者和贡献者一直在 CPython 的主分支上构建 JIT 编译器。我们首先要感谢他们。这是一项艰难且技术深度极高的工作，他们做得非常谨慎，最近性能的提升是真实且令人鼓舞的。以下内容绝非对该工作或其背后人员的批评。恰恰相反。正是因为该项目已经进行了很长时间，经历了多次重新架构，我们认为现在是重新评估 JIT 在项目中非正式状态的好时机。

当 JIT 最初被合并到主分支时，它是以实验的形式进入的，而关于它的唯一增强提案 PEP 744 是信息性的。该 PEP 在解释初始设计方面做了有价值的工作，甚至勾勒了 JIT 可能成为永久功能的标准，包括它明确留下的问题：长期维护者的承诺、安全审查、调试和进程外工具支持、运行时将做出的保证，以及 JIT 将对重新分发者和下游打包者施加的义务。

多年来，在该 PEP 和其他地方也有相当多的来回讨论，我们承认在此过程中发生了很多有用的沟通。我们要明确的是，我们并不是暗示作者有意绕过了正式流程。责任是共同的，包括我们自己：总的来说，我们（指导委员会）并没有像这种复杂性和影响力所应得的那样严格遵循流程。

PEP 744 中的那些开放问题（以及更多）正是社区应该通过 PEP 流程权衡并达成共识的承诺，而这些承诺尚未得到解决。因此，指导委员会正式要求编写一份 Standards Track PEP，供社区讨论，并由指导委员会正式接受（或拒绝），以论证 JIT 作为 CPython 中受支持的、非实验性部分的理由：其保证、维护承诺以及对重新分发者的影响。

在此类 PEP 被接受之前，我们要求不要在 JIT 上对主分支进行新的开发，包括新特性、优化和性能工作。错误修复和安全修复当然可以照常进行；具体要求是在 PEP 被接受之前，不要添加任何新的 JIT 功能。虽然目的并非要求提出竞争性提案，但我们认为现在是讨论和提出替代方案的好时机。

我们相信这种方法也符合我们之前的长期观点：在没有配套 PEP 的情况下，不应在 CPython 的主分支上进行实验。例如，与其提出一个具体的 JIT 实现，PEP 更合理的做法是描述一个能够支持多种实现策略的 JIT 基础设施。由于许多不同且有前景的 JIT 跟踪方法不断被提出，我们认为基础设施应该使在 CPython 内部实验和评估这些方法变得容易，而不是与单一策略高度耦合。

我们希望 PEP 至少解决以下几点：

• 维护：对于这样一个规模和复杂性的子系统，维护是一个实际问题。PEP 应制定明确的计划，说明如何长期维持和维护 JIT，以及它将如何影响不直接贡献 JIT 的维护者和贡献者。
• 兼容性：如何与现有 CPython 特性和工具保持兼容。JIT 如何与 CPython 已支持的功能交互，并对其做出什么保证。这包括自由线程、分析器和调试器等，但 PEP 应广泛且细致地处理这些问题，而不是作为固定的检查清单。
• 成功指标和时间表：项目要达到的目标和时间，例如性能目标、平台覆盖率和内存开销。
• 与其他 JIT 编译器的关系：设计是否旨在提供其他工作可以构建的通用基础设施，以及是否期望与第三方 JIT 实现（如 CinderX、Numba 和 PyTorch 或任何其他第三方 JIT）兼容或不兼容。
• 架构稳定性：当前的 JIT 架构是否被认为是稳定的，或者可能会进一步改变。

这个列表并非详尽无遗。它旨在表明我们希望 PEP 涉及的问题类型，并且我们预计随着社区讨论的进展，将会增加更多要点。

我们设定了六个月的窗口期来提交和解决 PEP。如果在此期间内没有此类 PEP 被接受，则必须将 JIT 代码从主分支中移除，并且开发必须继续在 Python 主仓库之外进行。

我们知道这要求那些投入多年工作的人做出一些牺牲，我们不会轻率地对待这一点。我们认为这并非要终止项目，而是为项目和社区提供清晰度和明确的承诺，这种程度的变更对于 CPython 的运行时来说是应得的。

感谢您的理解，以及您迄今为止所做的一切。

— Python 指导委员会

---

社区讨论摘要

Antoine Pitrou 认为该决定非常合理，但询问是否有进一步的背景。

Peter Bierma 质疑六个月期限是否现实，指出类似规模的 PEP 703 从提交到接受花了约五个月。

Thomas Wouters 解释称背景是委员会已讨论了一段时间，涉及 JIT 与仪器、调试和分析的协作，以及外部 JIT（如 CinderX）和相关项目（如 Numba、PyTorch 编译）的存在。没有单一触发事件，选择时机是为了不影响 3.15 的 beta 截止。

Pablo Galindo Salgado 强调委员会会灵活处理，不会机械执行截止日期，必要时可申请延期。

Diego Russo 同意 JIT 需要正式的 PEP，并愿意协调编写工作。

Mark Shannon 担心暂停开发会导致动力丧失和新贡献者流失，请求一到两个月的宽限期以继续开发并充分讨论 PEP。

Savannah Ostrowski 认为宽限期不是必需的，因为 PEP 的评估不会仅基于当前状态，启动社区讨论有助于塑造 PEP。

Thomas Wouters 补充说，在讨论期间不应让 JIT 成为移动目标，以免模糊讨论焦点。

Mark Shannon 回应称宽限期不是为了增强 PEP 的说服力，而是为了维持工作节奏，否则 PR 会腐烂，贡献者可能失去兴趣。