整理 | 屠敏出品 | CSDNIDCSDNnewsPython 社区正在经历一次不太常见的“内部刹车”事件。近日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/5252079https://discuss.python.org/t/an-announcement-from-the-steering-council-regarding-the-jit-project/107638
Python JIT开发遭官方紧急叫停：六个月内重新补PEP，否则将彻底移除主干代码！
发布时间：2026/6/12 11:56:23
整理 | 屠敏出品 | CSDNIDCSDNnewsPython 社区正在经历一次不太常见的“内部刹车”事件。近日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/5252079https://discuss.python.org/t/an-announcement-from-the-steering-council-regarding-the-jit-project/107638
