Python 社区正经历一场罕见的“内部刹车”——指导委员会突然叫停了主分支上即时编译器（JIT）的全部新功能开发，仅允许修复 Bug 和安全更新，所有新功能、性能优化一律暂停。更关键的是，委员会给出了一个期限：未来 6 个月内，JIT 核心开发者必须提交一份正式的 PEP 提案；若逾期未能落地，JIT 代码将从 CPython 主分支中彻底删除。
这个消息让很多开发者措手不及。毕竟，CPython 的 JIT 编译器项目一直是 Python 3.13/3.15 性能路线的核心部分，在 x86-64 Linux 上已实现约 8–9% 的几何平均性能提升。那么，为什么说停就停了？
从“实验功能”到“治理争议”
事实上，JIT 并非一开始就作为正式特性进入主分支。它最初以“实验性质”加入，对应的是 PEP 744，但这只是一个 Informational PEP，并未完成标准功能所需的完整治理闭环。PEP 744 中留了一堆“未解决问题”，包括长期维护团队、安全性审查、调试器与工具链支持、对下游发行版的影响等，几年下来始终没有形成统一方案。
指导委员会成员 Pablo Galindo Salgado 也坦言，此前对高复杂度核心功能的监管过于松弛：“对于如此复杂、影响范围如此广的变更，我们在流程执行上的把控不够严格。”
现在，委员会要求 JIT 团队在 6 个月内重新起草一份正式 PEP，明确 JIT 的官方定位、维护机制、生态兼容性等核心问题。同时，委员会建议开发者不要局限于现有方案，可考虑搭建通用 JIT 基础设施，方便对比多种优化策略。
新 PEP 必须至少解决以下几个关键问题：
- 维护承诺：JIT 将如何长期维护？它会对不直接参与 JIT 开发的维护者带来哪些负担？
- 兼容性保证：如何与 CPython 现有特性（例如 free-threading、性能分析器、调试器）协同工作？提供什么样的保证？
- 成功标准与时间表：明确可衡量的性能目标、平台覆盖范围、内存开销等，并给出里程碑。
- 与其他 JIT 的关系：该设计是通用基础设施，还是与 CinderX、Numba、PyTorch 等第三方 JIT 兼容或互斥？
- 架构稳定性：当前的 JIT 架构是否仍可能发生剧变？
Pablo Galindo Salgado 表示，以上只是问题示例，随着社区讨论推进，还会补充新的关注点。
社区争议：核心开发者反对冻结，赞同声也此起彼伏
面对这一政策变动，社区迅速分裂。JIT 核心开发者 Mark Shannon 直言：“在新 PEP 获批前叫停所有开发，让我们进退两难。”他认为，这迫使团队仓促制定新提案，而社区根本没有足够的讨论时间。据他透露，团队原计划是今年晚些时候再推出新提案，届时编译器的性能提升会更显著。Mark Shannon 因此申请了一到两个月的宽限期，担忧暂停会导致项目失去动力，并让近期吸纳的新贡献者流失。当被问到能否在分支仓库中继续开发时，他表示并不可行——由于优化代码的生成机制特殊，分支与主分支的差异会极大，难以维护。
另一边，不少开发者却认为指导委员会的决定合情合理——JIT 早已不是“小实验”，若要成为 CPython 的核心组件，必须走标准 PEP 流程，否则会破坏 Python 一贯的治理一致性。
结语
这次整改标志着 Python 官方彻底收紧主分支的实验性功能规则，终结了 JIT 多年来“边做边试、无正式规范”的迭代模式，核心功能的升级全面回归标准化社区共识机制。Pablo Galindo Salgado 强调：“我们并非要终止这个项目，而是要让项目本身以及社区获得清晰的说明和明确的承诺，以应对 CPython 运行时如此重大的变革。”
然而，现实是，JIT 项目的前景因此蒙上阴影。此前它几乎确定会成为 CPython 的官方组成部分，如今变数陡增。要在六个月内完成一份 PEP 提案并达成共识，时间本就紧张；一旦 JIT 代码真的被移除主分支，项目节奏必然大幅放缓。
对此，你怎么看？欢迎来云栈社区一起聊聊。
参考链接：
| 
发表于 昨天 21:27
|
查看: 12|
回复: 0
