The JIT made it in—but approval didn’t
Python’s experimental JIT compiler arrived in CPython 3.13 as an opt-in feature, building on work started in late 2023 and early 2024. Core developer Brandt Bucher initially merged the copy-and-patch JIT, intending it to boost runtime performance.
However, the JIT never secured formal, long-term approval. It shipped under PEP 744, an Informational PEP that merely described the feature, rather than a Standards Track PEP that would have cemented its place and commitment to ongoing maintenance. This procedural gap left its future uncertain from the start.
This wasn't a bug-driven reversal; the code itself functioned. Instead, the Python project allows experimental features to ship without a permanent commitment, creating a space for innovation that doesn't automatically burden the core team with indefinite support. The JIT’s removal stems from this lack of formal consensus, not a technical failing.
The Python Steering Council ultimately delivered an ultimatum: secure a Standards Track PEP or the JIT would be removed. This move underscored that while shipping experimental code is one thing, convincing the community and maintainers to commit resources indefinitely is a far greater challenge in open source development.
The council asked for proof, not promises
Python’s steering council, unimpressed by the JIT’s informal introduction, issued an ultimatum in June 2026: submit and pass a Standards Track proposal within six months, or the experimental JIT code would be excised from the main branch. This wasn't a suggestion; it was a hard deadline for a feature that had sidestepped standard governance.
In response, Savannah Savannah Ostrowski, Ken Jin, and Brandt Bucher submitted PEP 836, aptly titled "JIT Go Brrr: The Path to a Supported JIT Compiler for CPython," in July 2026. The council’s 10-point critique was swift and unforgiving. They slammed the PEP for insufficient attention to security, labeling it an "underserved area," and dismissed its performance and user impact projections as "overly optimistic."
Perhaps the most damning rejection concerned the proposed compatibility review, slated for the Python 3.17 release candidate in August 2028. The council deemed this timeline "way, way too late," underscoring their demand for immediate, ironclad assurances. Without a convincing roadmap, the JIT’s future looked increasingly bleak, despite its initial promise.
A promising proposal ran out of people
The Python Steering Council’s ultimatum hung heavy, but a promising proposal couldn't find its footing. On October 19, 2026, Savannah Savannah Ostrowski—release manager for Python 3.16 and 3.17—formally withdrew PEP 836, the “JIT Go Brrr” proposal intended to elevate the JIT to standards-track status. Her stated reason: a stark lack of “personal bandwidth to carry the current version forward.”
This wasn't a declaration that JITs were worthless; quite the opposite. Savannah Ostrowski and her team remained convinced of the technology's potential to boost Python’s performance. The withdrawal reflected the sheer engineering and political effort required to satisfy the council’s rigorous demands, which included addressing security concerns and demonstrating more robust performance gains than the modest 4–12% geometric mean speedups observed in narrow benchmarks.
Council feedback had been blunt, calling security an "underserved area" and deeming the proposed August 2028 compatibility review for Python 3.17 "way, way too late." Without the dedicated resources to comprehensively tackle these points, PEP 836 couldn't proceed. For background on the JIT's initial, less formal introduction, see PEP 744 – JIT Compilation.
The consequence is now all but certain: the experimental JIT code will be removed from CPython’s main branch early in the Python 3.16 development cycle. Python's brief flirtation with an in-tree JIT appears to be over, a victim of open-source realities where code shipping is often the easiest part.
Enjoying this? Get one like it in your inbox each morning.
one email a day · unsubscribe in two clicks · no third-party tracking
The real bottleneck is long-term ownership
Merging code is the beginning, not the end, of open-source development. The JIT’s impending removal from CPython’s main branch illustrates a crucial lesson: ownership extends beyond initial commits. Maintainers face ongoing responsibility for security reviews, compatibility risks, memory costs, and long-term support—a burden the JIT team, despite their belief in the technology, could not sustain.
This outcome should not be misconstrued as a halt to Python performance efforts. The JIT was an experimental, opt-in feature. Much of CPython’s recent speed gains, including the substantial improvements in Python 3.11 and 3.12, stemmed from the specializing adaptive interpreter, a distinct and ongoing optimization strategy.
Furthermore, this decision does not spell the end for Python JIT development writ large. Alternative projects like PyPy, Numba, and PyTorch Inductor continue to leverage JIT compilation. These solutions, addressing different workloads and execution environments, operate outside CPython’s core development track, demonstrating that the JIT concept remains vital for specific high-performance Python applications.
Frequently Asked Questions
Why is CPython removing its experimental JIT?
The JIT lacked an approved Standards Track PEP, faced unresolved security and compatibility concerns, and its maintainers could not commit the bandwidth needed to carry the proposal forward.
Was the JIT removed because it had bugs?
No. The decision centered on governance, long-term maintenance, security review, and whether the expected benefits justified the costs.
What was the difference between PEP 744 and PEP 836?
PEP 744 documented the experimental JIT but was informational. PEP 836 sought formal approval for a supported JIT, but its lead author withdrew it.
Does this mean Python will never have a JIT?
No. The decision concerns the JIT in CPython’s main branch; independent projects and future proposals can still pursue JIT compilation.