本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

Python’s experimental JIT to be removed

The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider accepting the trial offer on the right. Thank you for visiting LWN.net!

以下内容仅供订阅者阅读，由一位 LWN 订阅者提供。成千上万的订阅者依赖 LWN 获取来自 Linux 和自由软件社区的最佳新闻。如果您喜欢这篇文章，请考虑接受右侧的试用优惠。感谢您访问 LWN.net！

Try LWN for free for 1 month: no payment or credit card required. Activate your trial subscription now and see why thousands of readers subscribe to LWN.net.

免费试用 LWN 1 个月：无需付款或信用卡。立即激活您的试用订阅，看看为什么成千上万的读者订阅了 LWN.net。

Python’s experimental just-in-time (JIT) compiler, which was added to CPython in 2024 for the 3.13 release, is on its way out. In June, the Python steering council announced that it was pausing work on the JIT in CPython’s main branch until there was an accepted Python Enhancement Proposal (PEP) that addressed concerns about maintenance, compatibility, and set clear success metrics as well as a timeline for completion. After creating PEP 836 (“JIT Go Brrr: The Path to a Supported JIT Compiler for CPython”) to try to meet the council’s request, and after months of discussion, the JIT maintainers have withdrawn the PEP. For now, it appears that development on the once-promising project has come to an end.

Python 的实验性即时（JIT）编译器于 2024 年随 3.13 版本加入 CPython，目前正面临被移除的命运。今年 6 月，Python 指导委员会宣布暂停 CPython 主分支中 JIT 的开发工作，直到有一份被采纳的 Python 增强提案（PEP）能够解决关于维护、兼容性的担忧，并设定明确的成功指标及完成时间表。在创建了 PEP 836（“JIT Go Brrr：CPython 支持的 JIT 编译器之路”）以试图满足委员会的要求，并经过数月的讨论后，JIT 维护者撤回了该提案。目前看来，这个曾经充满希望的项目开发工作已经告一段落。

The JIT was added to CPython by Brandt Bucher in early 2024. Generally, such a major feature would be expected to land only after the council had approved a standards-track PEP. Bucher had given a talk (YouTube video, slides) about the JIT at a Python core developer sprint, and announced his intent to merge the feature—but he had not taken the step of authoring or submitting a PEP for its approval. He was prodded into doing so by steering council member Thomas Wouters, who was also serving as the release manager for Python 3.13.

JIT 是由 Brandt Bucher 在 2024 年初加入 CPython 的。通常情况下，如此重大的功能只有在委员会批准了标准跟踪 PEP 后才会被合并。Bucher 曾在 Python 核心开发者冲刺会议上就 JIT 发表过演讲（YouTube 视频，幻灯片），并宣布了他合并该功能的意图——但他并未采取撰写或提交 PEP 以供批准的步骤。在指导委员会成员 Thomas Wouters（同时担任 Python 3.13 的发布经理）的敦促下，他才开始着手处理此事。

Bucher and Savannah Ostrowski drafted PEP 744 (“JIT Compilation”), which was an informational PEP—meaning it only provides information to the Python community and does not represent formal consensus to proceed on a feature or project. LWN covered the discussion of PEP 744 in April 2024, and later covered Bucher’s talk on the JIT at PyCon US 2024, as well as the follow-up talk at PyCon US 2025.

Bucher 和 Savannah Ostrowski 起草了 PEP 744（“JIT 编译”），这是一份信息性 PEP——意味着它仅向 Python 社区提供信息，并不代表推进某项功能或项目的正式共识。LWN 在 2024 年 4 月报道了关于 PEP 744 的讨论，随后报道了 Bucher 在 PyCon US 2024 上关于 JIT 的演讲，以及在 PyCon US 2025 上的后续演讲。

Work on the JIT had been proceeding on the basis of PEP 744 until this June, when the council had put forward its formal request for the JIT maintainers to create a standards-track PEP. One might wonder, as Antoine Pitrou did, why the council had decided that it was time to speak up and ask for a new PEP. Wouters said that there was no “single triggering event for this request”, but that the council had been discussing the topic for a while and indicated that it was looking to ensure the JIT work did not interfere with other projects. “There’s been work trying to get the JIT to play nice with instrumentation, debugging, and profiling. There’s also external JITs (like CinderX), JIT-adjacent things (like Numba and PyTorch’s compile), and discussions about a tier 3 JIT.” The council had waited until after the Python 3.15 beta release “to be clear that we’re OK with the status quo for 3.15”.

JIT 的工作一直基于 PEP 744 进行，直到今年 6 月，委员会正式要求 JIT 维护者创建一个标准跟踪 PEP。人们可能会像 Antoine Pitrou 那样好奇，为什么委员会决定现在站出来要求一份新的 PEP。Wouters 表示，这次请求并没有“单一的触发事件”，但委员会已经讨论该话题一段时间了，并表示希望确保 JIT 的工作不会干扰其他项目。“目前有工作试图让 JIT 与仪器化、调试和性能分析良好兼容。此外还有外部 JIT（如 CinderX）、与 JIT 相关的项目（如 Numba 和 PyTorch 的编译），以及关于三级 JIT 的讨论。”委员会等到 Python 3.15 测试版发布后才提出要求，“以明确我们对 3.15 的现状是满意的”。

The council asked for a PEP that would make the case for the JIT “as a supported, non-experimental part of CPython: its guarantees, its maintenance commitments, and its impact on redistributors”. The council set a deadline of six months for the PEP to be submitted and accepted; failing that, the council would require the JIT code to be removed from the CPython main branch.

委员会要求提供一份 PEP，论证 JIT 作为“CPython 受支持的、非实验性部分”的合理性：包括其保证、维护承诺以及对重新分发者的影响。委员会设定了六个月的期限供提交并采纳该 PEP；如果失败，委员会将要求从 CPython 主分支中移除 JIT 代码。

Bucher, Ostrowski, and Ken Jin drafted PEP 836 and published it on the Python forum for community feedback on July 3. It generated quite a bit of discussion, some favorable and some critical. One of the key themes in the comments, such as this one by Wouters, and this comment by Mark Shannon, was that the draft felt like it should be two separate PEPs. Shannon, for example, thought that the PEP should only cover goals for accepting the JIT work and felt that it should leave out implementation details. There were also quite a few calls for additional information.

Bucher、Ostrowski 和 Ken Jin 起草了 PEP 836，并于 7 月 3 日发布在 Python 论坛上以征求社区反馈。这引发了相当多的讨论，既有赞成的也有批评的。评论中的一个关键主题（例如 Wouters 的这条评论和 Mark Shannon 的这条评论）是，草案感觉应该拆分为两个独立的 PEP。例如，Shannon 认为该 PEP 应该只涵盖接受 JIT 工作的目标，而不应包含实现细节。此外，还有不少要求补充更多信息的声音。

Bucher pushed back a bit on the suggestion that it should be two PEPs, and Ostrowski defended the structure of the PEP as it was. “Outlining goals like we have in the PEP without being able to share the plan and everything we’ve thought through alongside it would make me uncomfortable. To me, goals without plans behind them aren’t really goals at all.”

Bucher 对拆分为两个 PEP 的建议表示了一些抵触，而 Ostrowski 则为 PEP 的现有结构进行了辩护。“如果在 PEP 中列出目标，却不能分享背后的计划以及我们思考过的一切，我会感到不安。对我来说，没有计划支撑的目标根本算不上目标。”

When we last looked at this topic in September, the discussion about the PEP had slowed down without a commitment to develop new PEPs or a formal statement from the council. The last word from the council at that time, in the form of a summary of its August 6 meeting, was that it had met with the PEP authors and was “discussing the state of the PEP and whether it answered the questions the SC asked in its request for a PEP”.

当我们上次在 9 月关注此话题时，关于 PEP 的讨论已经放缓，既没有承诺开发新的 PEP，也没有来自委员会的正式声明。当时委员会的最后表态（以 8 月 6 日会议纪要的形式）是，它已经与 PEP 作者会面，并正在“讨论 PEP 的状态，以及它是否回答了指导委员会在 PEP 请求中提出的问题”。

On September 21, Wouters posted a statement from the steering council, minus Ostrowski (who is currently a member of the steering council but did not participate since she is a co-author of the PEP), that summarized its position. The statement said that PEP did answer all of the questions that were highlighted in the council’s request, “although perhaps some less convincingly than others”.

9 月 21 日，Wouters 发布了一份来自指导委员会的声明（Ostrowski 除外，她目前是指导委员会成员，但因是 PEP 的共同作者而未参与），总结了其立场。声明称，该 PEP 确实回答了委员会请求中强调的所有问题，“尽管有些回答可能不如其他回答那样令人信服”。

The council wished to make clear that it was not looking for the criteria that the JIT should meet to be a supported feature, or whether it should be considered such. Instead, the council was evaluating whether the JIT should continue as an experiment in CPython’s main branch.

委员会希望明确指出，它并不是在寻找 JIT 成为受支持功能所需满足的标准，也不是在讨论它是否应该被视为受支持功能。相反，委员会是在评估 JIT 是否应该继续作为 CPython 主分支中的一个实验项目存在。

The council said that the PEP was not specific enough about support plans, performance criteria, and too vague or too optimistic about a number of other areas. The statement included a ten-point list of items that the council wanted “to see either spelled out in the PEP, or at least discussed and rejected”. The council’s list expressed concerns ranging from memory impact to security. For example, on the topic of platform parity, the council wanted to ensure that the JIT was designed to be easily adopted for new platforms. It wa

委员会表示，该 PEP 在支持计划、性能标准方面不够具体，在其他许多领域也过于模糊或过于乐观。声明中包含了一份十点清单，委员会希望“在 PEP 中明确说明，或者至少进行讨论并予以驳回”。委员会的清单表达了从内存影响到安全性的各种担忧。例如，在平台对等性方面，委员会希望确保 JIT 的设计能够轻松适配新平台。它 wa