Python JIT gets a six-month PEP ultimatum or is removed from main

The Python Steering Council just put the experimental JIT compiler on a calendar with teeth: either a new, accepted PEP arrives within six months, or the JIT code gets removed from the main branch. New development on the JIT project is paused in the meantime, but bug and security fixes for existing JIT code in main will still be accepted. The deadline is the real headline, because six months is a sprint for a standards-style document and review cycle, not just a software update.

Why does this matter right now? Because an improved JIT compiler is one of the key features of Python 3.15, which is in features-freeze mode. The full release is expected in October, and the release notes promise "8-9 percent geometric mean performance improvement" over the standard CPython interpreter on x86-64 Linux. That promise is already tied to the product direction. The Steering Council action, therefore, threatens what many people thought would be a straight line from experimental code into a marquee performance feature.

To understand the conflict, zoom in on the mechanics. The JIT compiler is experimental and disabled by default. To use it, you have to set PYTHON_JIT=1 as an environmental variable. So yes, this is not “turn on everywhere by default tomorrow.” But it is still code sitting in the main repository, which is the gravitational center of the CPython universe. Once something is in main, it stops being a side project and starts being a dependency for anyone who watches the branch, tests against it, or builds tooling around it.

The Steering Council says the issue is process, not performance. Pablo Galindo Salgado, a Council member, wrote that "We (the Steering Council) have not been as strict about following the process as a change of this complexity and reach deserves," according to the post described in The Register. The implied concern is that the experimental JIT compiler was merged into main without following “proper process” for changes of this scope. In particular, PEP 744, which relates to the JIT, is only informational and contains open questions.

Those open questions are exactly what slows down serious governance. They include future maintenance of the JIT, compatibility with existing CPython features and tooling, clear and measurable success metrics, and the relationship to third-party JIT compilers. That list is the kind of stuff that becomes a board-level problem when software shifts from “nice experiment” to “strategic capability.” You can ship features. You can also end up with a maintenance burden, ecosystem fragmentation, unclear performance measurement, and pressure from competing approaches.

The JIT contributors are describing this as a momentum trap. Key JIT contributor Mark Shannon said "stopping all development until a PEP is accepted puts us in an awkward position," because it forces the team to produce a new PEP quickly, but not in a way that gives the community time to discuss it. Shannon said a new PEP was already planned for "later this year when the performance advantage would be larger." He also asked for a grace period of "a month or two" to continue work, warning that "a moratorium risks loss of momentum and losing the new contributors we have recently gained." He further explained that continuing in a fork is not easy, because of how optimizations are generated, leading to very large code differences that are hard to manage.

Other Council members reinforced the “official PEP” framing. Donghee Na said "the current experimental JIT project needs an official PEP" and that this would be a good time to review different possible approaches. That matters because fast-tracking a PEP with “different possible approaches” is difficult when the discussion is inherently broad. Thomas Wouters added that there is “some flexibility around the six-month deadline,” saying "We’re not unreasonable, but we do want this to be taken seriously."

There is a second-order strategic angle here for anyone tracking Python’s roadmap. Galindo and Wouters raised the possibility of shifting towards "a JIT infrastructure that can support multiple implementation strategies," and hinted they would prefer an infrastructure that is not "highly coupled with a single strategy." Translation: the Council may be setting the stage for a more modular, ecosystem-friendly future, rather than locking CPython development around one JIT approach. But that also raises the cost of delay, because multi-strategy infrastructure work can take longer than a single targeted compiler iteration.

So what is the stake for executives, investors, and operators watching language ecosystems? It is simple: Python 3.15’s announced performance lift is suddenly coupled to governance theater. If the JIT code is removed from main after six months, the project likely loses momentum, and the timeline for any “JIT-as-a-feature” future gets murkier. Even if the JIT survives, the process dispute signals that major runtime changes will face stricter compliance with PEP expectations going forward. In a world where developer tools, libraries, and performance benchmarking workflows often treat “main branch” as the early warning system, this is not just a technical decision. It is an ecosystem decision, with real consequences for planning, integration, and resource allocation.