CPython's JIT set for removal after PEP 836 withdrawn

The experimental just-in-time (JIT) compiler in CPython, the standard Python interpreter, is expected to be removed from the project's main branch. Its authors withdrew PEP 836, the proposal meant to make the JIT an official feature, on October 19, 2026. LWN.net reported on October 26 that the code will likely come out "fairly soon," ideally early in the Python 3.16 cycle. That ends, for now, the effort to make standard Python faster with a compiler built into the interpreter.

A JIT turns frequently run Python code into machine code while the program runs. Official Windows and macOS builds of Python 3.15 include one as an experiment, switched off by default.

How the JIT got here

The trigger was a June 5, 2026 announcement from the Python Steering Council, the group that governs the language. It asked for a formal proposal, called a Standards Track PEP (Python Enhancement Proposal), making the case for the JIT as a supported part of CPython.

The council set firm terms:

Rule	Detail
New JIT work	No new features, optimizations or performance work on main until a PEP is accepted
Still allowed	Bug fixes and security fixes
Deadline	Six months to submit and resolve a PEP
If no PEP is accepted	"the JIT code must be removed from the main branch"
Python 3.15	The council was "okay with the status quo for 3.15"

The council said it did not think the JIT team had bypassed the process. It admitted that it had not been strict enough about process itself.

What PEP 836 proposed

Savannah Ostrowski, Ken Jin and Brandt Bucher wrote PEP 836, titled "JIT Go Brrr," aimed at Python 3.16. It did not ask for the JIT to be declared supported right away. It proposed a time-limited path with measurable goals.

• With the GIL: the JIT build at least 5% faster than the normal interpreter in year one. The GIL, or global interpreter lock, is the lock that lets only one thread run Python code at a time.
• Free-threaded: at least 20% faster than the free-threaded interpreter by the first beta of Python 3.17.
• Design change: move from recording traces of hot code to compiling whole methods.

LWN reports that the council answered on September 21. It said the PEP answered its questions, though some answers were less convincing. It still wanted more on security, platform support and behavior users can see. It called a compatibility review planned for the first 3.17 release candidate "way, way too late."

According to InfoWorld, the council also said the PEP lacked detail on long-term support, performance testing and debugging tools. It called the speed goals overly optimistic.

Why the authors withdrew

"We don't feel we have the personal bandwidth to carry the current version forward," Ostrowski wrote, as quoted by InfoWorld. "The Steering Council rightly sets a high bar for a proposal of this scope," she added. The team still believes in "the technical direction outlined in the PEP," she said.

LWN notes that Ostrowski is release manager for Python 3.16 and 3.17. The withdrawal post said the reference code would be published and linked from the PEP.

The gains were real but modest. PEP 836 reports a 4-12% geometric-mean speedup in Python 3.15 across the main platforms. InfoWorld says the gains helped mainly some kinds of programs, such as long-running tight loops.

What this means for developers

Most Python users never turned the JIT on, so day-to-day code is unaffected. A few groups should still act.

• Python 3.15 is unchanged. The council accepted the status quo for 3.15. If you set PYTHON_JIT=1 today, it keeps working on that release.
• Do not plan around a JIT in 3.16. Removal is expected early in the 3.16 cycle. Treat any speedup you measured on 3.15 as temporary.
• Simpler builds ahead. JIT builds need LLVM, a compiler toolkit, at build time. Teams that build Python from source can likely drop that step later.
• Look elsewhere for speed. The council itself named separate JIT projects such as CinderX, Numba and PyTorch. Profile your code first, then pick the tool that fits the hot path.
• Forks may continue. Brett Cannon said that stopping work in main does not stop it elsewhere, LWN reports. Any revived JIT would face the same high bar to come back.

Python 3.15.0 shipped on October 9 with a faster JIT as one of its headline changes. Less than three weeks later, that same JIT has no path to becoming official.