Glonce

CPython's experimental JIT likely to be removed after PEP 836 is withdrawn

toolsThe Glonce editorsHacker News🔥75Glonce rating75Impact60Novelty40Relevance90Surprise65Players55Credibility90

CPython's experimental just-in-time (JIT) compiler, added in 2024 for the 3.13 release, is on its way out. In June the Python steering council announced it was pausing work on the JIT in CPython's main branch until there was an accepted Python Enhancement Proposal (PEP) covering maintenance, compatibility and clear success metrics, with a timeline for completion. The council gave the JIT maintainers six months to get that PEP submitted and accepted; failing that, it would require the JIT code to be removed from main. The maintainers wrote PEP 836 ("JIT Go Brrr: The Path to a Supported JIT Compiler for CPython"), and after months of discussion they withdrew it on October 19.

The background: Brandt Bucher added the JIT in early 2024. A feature of that size would normally land only after the council approved a standards-track PEP, but Bucher had announced his intent to merge it without one. Steering council member Thomas Wouters, then also release manager for Python 3.13, prodded him to write a PEP. Bucher and Savannah Ostrowski drafted PEP 744 ("JIT Compilation"), which was only informational: it gives information to the community and does not represent formal consensus to proceed. Work continued on that basis until June, when the council formally asked for a standards-track PEP. Asked by Antoine Pitrou why now, Wouters said there was no single triggering event. The council had been discussing the topic for a while and wanted to make sure the JIT work did not interfere with other projects: work on getting the JIT to play well with instrumentation, debugging and profiling, external JITs such as CinderX, JIT-adjacent things such as Numba and PyTorch's compile, and discussions about a tier 3 JIT. The council waited until after the Python 3.15 beta to make clear it was fine with the status quo for 3.15. It asked for a PEP making the case for the JIT as a supported, non-experimental part of CPython: its guarantees, maintenance commitments and impact on redistributors.

Bucher, Ostrowski and Ken Jin published PEP 836 on the Python forum on July 3. Reaction was mixed. A recurring theme, voiced by Wouters and by Mark Shannon among others, was that it should be two PEPs; Shannon thought it should cover only the goals for accepting the JIT and leave out implementation details. Bucher pushed back, and Ostrowski defended the structure: "goals without plans behind them aren't really goals at all." By September the discussion had slowed. The last word from the council, a summary of its August 6 meeting, said it had met the authors and was discussing whether the PEP answered its questions.

On September 21, Wouters posted a council statement, without Ostrowski, who sits on the council but recused herself as a PEP co-author. It said the PEP did answer all the questions in the council's request, "although perhaps some less convincingly than others". The council stressed that it was not deciding whether the JIT should become a supported feature, only whether it should continue as an experiment in main. Experimenting in main brings a lack of unified design and uncertainty for core developers, package maintainers and users when behaviour and API surfaces change. The statement said the PEP was not specific enough about support plans and performance criteria, and too vague or too optimistic elsewhere, and it included a ten-point list of items to spell out or at least discuss and reject, ranging from memory impact to security. On platform parity, the council wanted assurance that the JIT could easily be adopted on new platforms and would not need platform-specific knowledge to maintain. It called the PEP "overly optimistic" about user-visible differences with the JIT enabled, since users depend on interpreter idiosyncrasies, and asked how such differences would be handled. It called security "an underserved area" and suggested talking to the Python security response team, with a security review part of the criteria for supported status. PEP 836 put its compatibility review, which would run the test suites of top PyPI packages to see whether the JIT broke them, at the first Python 3.17 release candidate, expected around August 2028. The council said that was "way, way too late" and wanted continuous review starting as soon as possible. It also worried about JIT design decisions made without critical review by the wider group of developers responsible for CPython. Its bottom line was that the PEP "mostly answers the questions we asked", but it wanted more discussion to gauge community support and consensus. Jin thanked the council a few days later and said the group would work on the suggestions.

Then came the withdrawal. Ostrowski, who is also release manager for Python 3.16 and 3.17, wrote that the council "rightly sets a high bar for a proposal of this scope" and that the authors did not feel they had the personal bandwidth to carry the current version forward. They still believe in the technical direction, including free-threaded support and a method-based frontend, and remain optimistic about the JIT's potential in CPython. They will make the reference implementation available and link it from the withdrawn PEP. Barry Scott asked whether this meant JIT work had stopped. Brett Cannon replied that it would stop in the main repository, but whether it continues elsewhere is up to the community. When Dunc Graham suggested an alternative PEP might still beat the deadline, Cannon said that was unlikely, since everyone actively driving the JIT was an author of or contributor to PEP 836.

The LWN author expects the JIT to be removed from main fairly soon, so any problems from the removal can be dealt with early in the Python 3.16 development cycle. It is unclear whether the original drivers intend to keep working on it at all, or whether it will be left for others to pick up if there is enough community interest. The author emailed the PEP authors for clarification and had not had a reply at the time of writing.

Key facts

  • PEP 836, the proposal to make CPython's experimental JIT a supported feature, was withdrawn on October 19 by its authors Brandt Bucher, Savannah Ostrowski and Ken Jin.
  • In June the steering council paused JIT work in main until a PEP was accepted, and set a six-month deadline; failing that, the JIT code would have to be removed.
  • The council's September 21 statement said PEP 836 mostly answered its questions but listed ten areas to spell out or discuss, including security, user-visible differences and an August 2028 compatibility review it called way too late.
  • Brett Cannon said JIT work stops in the main repository; whether it continues elsewhere is up to the community, and the reference implementation will be linked from the withdrawn PEP.
  • LWN expects the JIT to be removed from main fairly soon, but gives no exact date or version.

Why it matters

The JIT arrived in CPython 3.13 as an experiment. Its likely removal ends work on it in the main repository. It also shows how the steering council treats large features: even an experiment in main needs an accepted PEP with maintenance commitments, compatibility checks, security review and success metrics. The council was explicit that the question was whether the JIT may stay as an experiment, not whether it becomes supported.

Who it affects

Core developers, who would no longer maintain the JIT in main. The JIT maintainers (Bucher, Ostrowski and Jin), who said they lack the personal bandwidth to carry the current PEP forward. Package maintainers, users and redistributors, whose concerns about changing behaviour and API surfaces the council cited. Anyone following related work such as external JITs like CinderX, or Numba and PyTorch's compile, which the council named as context for its request.

How to use it

There is nothing to adopt here. The JIT was experimental, and the likely next step is its removal from main. Those who want to explore it can use the reference implementation, which the authors say they will make available and link from the withdrawn PEP. Whether anyone continues the work outside CPython is up to the community.

How solid is it

The withdrawal itself is solid: it is quoted from Ostrowski's announcement on October 19, and Cannon's replies are reported by LWN. The removal is not an announced decision. It is LWN's expectation that the JIT will likely be removed from main fairly soon. No exact date or version is given, and the article does not say whether the steering council has formally voted or issued a statement since the withdrawal. The authors had not replied to LWN's request for clarification at the time of writing.

Risks and caveats

The future of the project is unclear: it is not known whether the original drivers will keep working on it, or whether others will pick it up. Cannon said an alternative PEP before the deadline was unlikely because the active JIT developers were all tied to PEP 836. The article gives no performance figures for the JIT, so the cost of losing it cannot be judged from this account. The years for the dates in the story are not stated in the text.

“The Steering Council rightly sets a high bar for a proposal of this scope, and we don't feel we have the personal bandwidth to carry the current version forward.”

— Savannah Ostrowski, announcing the withdrawal of PEP 836