Python Steering Council Halts JIT Compiler Progress Over Process Failures
Table of Contents
A Sudden Brake on Performance Gains
The Python Steering Council has thrown a wrench into one of the most anticipated performance upgrades for the language, ordering an immediate suspension of new development on the experimental Just-In-Time (JIT) compiler within the main CPython repository. The move, which has blindsided project contributors, requires the team to draft and secure approval for a new Python Enhancement Proposal (PEP) before any further feature work can be merged.
While the Council will still accept bug fixes and critical security patches for the existing JIT code, the ultimatum is stark: if a comprehensive PEP is not submitted and approved within six months, the JIT code will be stripped from the main branch entirely. This creates a precarious situation for a project that was intended to be a cornerstone of the Python 3.15 release, expected in October.
The Process Gap
The conflict centers on governance rather than technical failure. According to the Steering Council, the current JIT implementation was merged into the main branch without a rigorous enough review process. PEP 744, which currently governs the JIT, is classified as “informational,” meaning it describes what is happening rather than establishing a formal, agreed-upon specification for the language’s future.
Pablo Galindo Salgado, a member of the Steering Council, admitted in a public post that the governing body had not been strict enough regarding the process. “We have not been as strict about following the process as a change of this complexity and reach deserves,” Salgado noted. The Council is now demanding answers to several “open questions,” including how the JIT will be maintained long-term, its compatibility with existing CPython tooling, and how success metrics will be measured against third-party JIT alternatives.
Developer Friction and Momentum Risks
For the developers on the ground, the timing is disastrous. Mark Shannon, a primary contributor to the JIT project, argued that a sudden moratorium puts the team in an “awkward position.” Shannon noted that a new PEP was already planned for later this year, intended to coincide with a phase where the performance advantages would be more pronounced and easier to quantify.
The tension highlights a classic struggle in open-source governance: the friction between rapid, experimental iteration and the rigid stability required by a language used by millions. Shannon warned that this pause risks a loss of momentum and could alienate new contributors who have recently joined the effort. He requested a grace period of one to two months to keep the project moving, noting that moving the development to a separate fork is impractical due to the massive code differences generated by the compiler’s optimizations.
Architectural Crossroads
Beyond the paperwork, there is a deeper architectural disagreement. Salgado indicated that the Council is less interested in a single, monolithic JIT strategy and is instead leaning toward a more flexible “JIT infrastructure” that could support multiple implementation strategies. This suggests the Council wants to avoid a scenario where CPython is tightly coupled to one specific JIT approach, potentially leaving the door open for alternative strategies or hybrid models.
Donghee Na, another council member, echoed the need for an official PEP, suggesting that this is the ideal moment to review various architectural approaches. However, the reality of the Python PEP process—which often involves months of community debate and iterative drafting—makes a “fast-track” approval unlikely.
While Thomas Wouters and other council members have suggested there is some flexibility regarding the six-month deadline, the message is clear: the JIT compiler will not be grandfathered into CPython based on performance alone. It must now survive the gauntlet of Python’s formal bureaucracy.
