The experimental just-in-time compiler, or JIT, for CPython will be removed after its maintainers missed deadlines for its formalization set by the Python Steering Council.
According to reporting at LWN.net, the move comes after the council formally paused work on the JIT in June 2026 until it approved a Python Enhancement Proposal, or PEP, that described how the JIT could become a properly supported part of CPython.
The JIT’s proponents, Brandt Bucher and Savannah Ostrowski, originally drafted PEP 744 to explain the JIT’s functionality, but this document did not explain how the JIT would be maintained and integrated in CPython. To answer that, they offered PEP 836, but still ran into pushback from the council, which found that PEP 836 lacked sufficient details about how the JIT would be supported, its performance would be evaluated, and how it would be integrated with debugging and profiling tools.
The council also criticized the PEP for being overly optimistic about the performance gains to expect. Speed improvements for the CPython JIT were measurable, but small, and only improved performance for some classes of programs, such as those with long-running tight loops.
On October 19, PEP 836 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,” Ostrowski said. “We continue to believe in the technical direction outlined in the PEP, including free-threaded support and a method-based front end, and remain optimistic about the JIT’s potential in CPython.”
Nothing forbids other developers from continuing where the JIT project left off. Withdrawing PEP 836 simply means that work on the JIT in the mainline edition of CPython won’t go forward. Other developers are free to continue the work in their own way, perhaps in an alternative build of CPython, although they will face the same high bar if they want to contribute that work back to CPython.
JIT projects for Python are not new. An alternative version of the Python interpreter, PyPy, uses a highly optimized JIT to speed up Python programs by an order of magnitude or more. But PyPy development lags the mainline version of CPython, and PyPy has experienced performance and compatibility issues with external C modules. Third-party projects like Facebook’s CinderX offer a JIT as an add-on, but they also are considered experimental.
The native JIT is far from the only project aimed at improving CPython’s performance. The core CPython team has paid more attention to improving native Python performance across the board over the last several years. One initiative that has shown significant results is the adaptive interpreter, introduced in Python 3.11, which uses type-specialized bytecode and (like the JIT) requires no rewriting of Python programs to deliver better performance.
Removing the JIT or relegating it to an out-of-band experiment won’t mean the quest for faster Python will come to an end. But it will mean any future project of this kind will need to meet a high bar for maintenance and measurability inside CPython.
