MyTechDailyNews Software Desk: CPython's JIT Pause Explained After PEP 836 Withdrawal

If you rely on Python tooling and are watching performance experiments in CPython, the most useful summary right now is this: the experimental JIT compiler that shipped with 3.13 will not become a supported feature through PEP 836, because the proposal was withdrawn after the Python steering council asked for clearer maintenance, compatibility, performance, and timeline commitments. The story began in 2024, moved through a Python Enhancement Proposal process, and reached a practical pause in 2025.

What happened, in one checklist

• Brandt Bucher added the experimental JIT to CPython in early 2024.
• Bucher and Savannah Ostrowski drafted PEP 744, an informational PEP titled JIT Compilation, rather than a standards-track PEP.
• In June, the steering council asked the maintainers to create a standards-track PEP for the JIT.
• PEP 836, JIT Go Brrr: The Path to a Supported JIT Compiler for CPython, was published for feedback.
• On October 19, the PEP authors withdrew it after months of discussion.

How the experiment entered the mainline

Brandt Bucher added the JIT to CPython in early 2024. A large runtime change would normally require a standards-track PEP before merging. Bucher had shared a YouTube talk and slides at a Python core developer sprint, but he had not submitted the proposal needed for council approval. Thomas Wouters, then a steering council member and release manager for Python 3.13, pushed for the formal step.

Bucher and Savannah Ostrowski drafted PEP 744 (JIT Compilation), an informational PEP that gave the Python community information but did not represent formal consensus to proceed. LWN covered the April 2024 discussion and later covered Bucher's talk at PyCon US 2024 and the follow-up talk at PyCon US 2025.

Why the steering council asked for a new PEP

The JIT moved from an experiment inside CPython to a governance problem in June. Antoine Pitrou asked why the steering council had chosen that moment. Thomas Wouters said there was no single triggering event for this request, but the council wanted the JIT work not to interfere with other projects. The council explained: 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 waited until after the Python 3.15 beta release to be clear that we're OK with the status quo for 3.15. It asked for a PEP that could present the JIT as a supported, non-experimental part of CPython: its guarantees, its maintenance commitments, and its impact on redistributors. The authors had six months to submit and accept the PEP; otherwise, the JIT code would be removed from the CPython main branch.

PEP 836 arrives and faces debate

Ken Jin joined Brandt Bucher and Savannah Ostrowski in drafting PEP 836, named JIT Go Brrr: The Path to a Supported JIT Compiler for CPython. The draft was published on the Python forum on July 3 for community feedback. Supporters and critics appeared in the same thread.

Mark Shannon and Thomas Wouters raised the point that the draft felt as if it should be two separate PEPs. Shannon preferred to separate acceptance goals from implementation details. Bucher pushed back on that suggestion. Ostrowski defended the structure, writing: 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.

September did not deliver a formal council verdict. The steering council had met with the PEP authors, and its August 6 summary said it was discussing the state of the PEP and whether it answered the questions the SC asked in its request for a PEP.

The council's ten-point concerns

On September 21, Thomas Wouters posted the steering council's statement, excluding Savannah Ostrowski because she was a co-author. The council said PEP 836 did answer the requested questions, although perhaps some less convincingly than others. The main question was not whether the JIT should be supported; the question was whether it should continue as an experiment in CPython's main branch.

The council wanted several issues to see either spelled out in the PEP, or at least discussed and rejected. In a ten-point list, it covered memory impact, security, platform parity, user impact, compatibility, support expectations, and governance.

On platform parity, the council wanted the JIT to be designed for easy adoption on new platforms, not tied to one platform. On user impact, it said the PEP was overly optimistic about visible differences. It noted that users depend on interpreter idiosyncrasies, as we've seen with other Python implementations or even just between major Python versions, and asked how differences would be treated if unavoidable. On security, the council called the topic an underserved area in the PEP and asked for discussion with the Python security response team.

The compatibility timeline drew a direct objection. PEP 836 had placed the compatibility review milestone at the first Python 3.17 release candidate, expected sometime in August 2028. The milestone would test suites from top PyPI packages to see whether the JIT broke them. The council replied: We think that's way, way too late, and the compatibility review should be an ongoing and continuous process starting as soon as possible.

The council also objected to major design decisions being made without critical review by the larger group of developers ultimately responsible for [CPython] development, maintenance and support. Its bottom line was that PEP 836 mostly answers the questions we asked, but that more discussion was needed to gauge community support and consensus before we're asked to pronounce on this PEP.

Withdrawal and what remains

Ken Jin thanked the steering council days later and said the group would work on the suggestions. The path changed after that. On October 19, Savannah Ostrowski, also release manager for Python 3.16 and 3.17, announced the PEP was withdrawn.

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. We continue to believe in the technical direction outlined in the PEP, including free-threaded support and a method-based frontend, and remain optimistic about the JIT's potential in CPython. We'll make the reference implementation available and link it from the withdrawn PEP so others who are interested can explore and build on that.

Barry Scott asked whether that meant the work had stopped. Brett Cannon replied that work in the main repository would be stopped, while community continuation elsewhere remained possible. Dunc Graham suggested an alternative PEP might still arrive before the six months deadline. Cannon said that was not likely, as all the people actively driving the JIT were either authors on that PEP or contributors to it.

Comparison table for software teams

Decision area	PEP 836 position	Steering council concern
Status	Continue the JIT as a supported path in CPython main	Decide whether mainline experimentation can remain without a clear plan
Process	One PEP combining goals and planning	Discussion of whether it should become two separate PEPs
Compatibility	Milestone near Python 3.17, with August 2028 timing discussed	Need earlier, continuous review using top PyPI package tests
Security	Security discussion was not sufficiently detailed	Need review with the Python security response team
Support	Aimed for non-experimental guarantees	Need clearer maintenance, performance, and redistribution impact

Step-by-step: what users should check now

1. Confirm whether you are using a stable CPython release or a development branch. If your environment was built from main during the 3.13 experimental window, treat any JIT behavior as provisional.
2. Review tests that depend on CPython internals, because the council's concerns highlighted behavior changes for core developers, package maintainers, and users.
3. If you distribute Python software through PyPI, keep a compatibility test plan tied to stable release versions rather than experimental JIT assumptions.
4. If you maintain performance-sensitive services, document which Python versions and compile flags were used, so future comparisons remain reproducible.

Data reference

The timeline cited above uses these anchors: early 2024, April 2024, June, July 3, August 6, September, September 21, October 19, six months, 3.13, 3.15, 3.16, 3.17, and August 2028.

Common misreadings

• Reading the withdrawal as a rejection of all Python performance work. The authors still believed in the technical direction, including free-threaded support and a method-based frontend.
• Confusing PEP 744 with a standards-track PEP. It was an informational PEP, not a formal approval.
• Assuming top PyPI packages had already passed the JIT compatibility review. The proposed milestone had not been completed.
• Treating 2028 as a guarantee. The council wanted ongoing compatibility review to start much earlier.

FAQ

Is the CPython JIT dead?

For CPython main, the PEP authors stopped pursuing the proposal, and work would be stopped in the main repository. Community continuation elsewhere remains possible.

Did the steering council say the JIT was insecure?

No. It said security was an underserved area in the PEP and asked for more review with the Python security response team.

Should developers switch Python versions?

The withdrawal affects the future supported status of the experimental JIT, not the day-to-day usability of stable Python releases. For production systems, the practical step is to stay on supported release versions and test any feature-flagged experimental behavior.

Action advice

MyTechDailyNews Software recommendation: do not build release plans around the JIT becoming a supported feature through PEP 836. Keep experiments isolated, maintain compatibility evidence for every Python version you support, and treat the reference implementation path mentioned in the withdrawal as optional research, not a production commitment.

With PEP 836 gone, the practical state is simple: the experimental JIT in CPython is paused, and its removal from main is expected soon so any regressions appear early in the Python 3.16 development cycle. For readers who care about software updates, the lesson is that runtime experiments need governance, compatibility proof, and maintenance commitments before they become dependable features.