CPython JIT 开发暂停，等待标准轨道 PEP

CPython JIT 开发因等待正式 PEP 而中止

Python 指导委员会（Steering Council）已正式要求暂停在 CPython 主分支中为实验性即时编译（JIT）编译器引入新功能、优化和性能工作。这一冻结状态将持续有效，直到编写、讨论并由委员会正式接受一份标准轨道 Python 增强提案（PEP），从而将 JIT 从实验状态转变为语言运行时的受支持、非实验性部分。

虽然新功能开发已暂停，但指导委员会明确表示，针对 JIT 的错误修复和安全修复可以照常进行。

对标准轨道 PEP 的要求

当前的 JIT 实现是以实验形式合并入主分支的，受 PEP 744 指导，该 PEP 被指定为“信息性”（Informational）而非标准轨道提案。指导委员会指出，JIT 编译器的复杂性和影响范围需要社区共识和正式承诺，而信息性 PEP 无法提供这一点。

为了推进工作，委员会要求提交一份新的 PEP，以解决以下关键领域的问题：

长期维护与可持续性

由于 JIT 子系统的规模和复杂性，该 PEP 必须概述一个清晰的长期可持续性计划。这包括 JIT 将如何被维护，以及其维护工作将对不直接参与 JIT 开发的核心贡献者产生哪些具体影响。

工具链与功能兼容性

提案必须定义 JIT 如何与现有的 CPython 功能和工具链进行交互，并保证其兼容性。具体的关注领域包括：

• Free-threading
• Profilers
• Debuggers

成功指标与时间表

委员会期望该项目有清晰、可衡量的目标，包括具体的性能目标、平台覆盖范围要求以及内存开销限制，并附带实现这些里程碑的时间表。

生态系统集成

该 PEP 必须澄清 JIT 与第三方 JIT 实现（如 Numba、PyTorch 和 CinderX）之间的关系。委员会建议，与其提供单一的具体实现，不如让 PEP 描述一种能够支持多种实现策略的通用 JIT 基础设施。

时间表与不合规的后果

指导委员会已设定了六个月的时间窗口用于提交并解决 PEP 问题。如果在该时间段内没有标准轨道 PEP 被接受，则必须从 CPython 主分支中移除 JIT 代码，且任何进一步的开发必须在主 Python 项目之外的独立仓库中进行。

社区反应与技术辩论

该公告引发了开发者之间关于工程严谨性与开发动力之间的平衡的大规模辩论。

支持冻结的观点

一些贡献者认为，此举是应用工程标准以防止 CPython 代码库变得过于复杂且缺乏明确维护计划的必要手段。一位评论者指出，鉴于之前实验性功能出现的问题（例如“YOLO GC debacle”），此举是合理的。

反对冻结的观点

批评者认为，在技术进步的关键时刻停止开发可能会扼杀项目的动力。一些观察者认为，要求提供通用的“基础设施”而非特定的实现，是一种旨在让 JIT 更难集成的“毒丸要求”（poison-pill requirement）。

对 Python 性能的看法

社区内的讨论凸显了在 Python 性能哲学上的分歧：

"CPython 的卖点在于其简单、足够快（配合 C 扩展）且代码易于理解。为了偶尔实现 50% 的提速（以及性能倒退 ...）而使代码库变得复杂，这并不值得。"

其他开发者则表达了希望 JIT 最终能够超越默认解释器，并指出在从 Python 2 到 Python 3 的过渡期间也曾见过类似的轨迹。