CPython Community Answers Steering Council's Six-Month JIT Ultimatum With PEP 836, a Path to a Supported Compiler

Overview

On June 5, 2026, Python’s Steering Council told core developers that new work on CPython’s experimental JIT compiler could no longer land on the main branch until a proper standards-track proposal governed the project — and gave the community six months to write one or watch the JIT come back out. The announcement, posted to Discourse by Council member Pablo Galindo Salgado, stated plainly: “We are setting a window of six months for a PEP to be submitted and resolved,” according to the Steering Council’s announcement. On July 3, three of the JIT’s own developers answered with PEP 836, “JIT Go Brrr: The Path to a Supported JIT Compiler for CPython,” laying out the performance and compatibility bar the compiler will have to clear to earn a permanent place in the interpreter.

What We Know

• The Council’s June 5 post stated: “Until such a PEP is accepted, we ask that no new development on the JIT land on main.” It added: “Bugfixes and security fixes may of course continue as normal,” according to the announcement on discuss.python.org.
• If no replacement PEP is accepted inside the six-month window, “the JIT code must be removed from the main branch and development must be continued outside the main Python repository,” the Council wrote in the same post.
• The Register reported that the trigger was procedural rather than technical: Galindo Salgado said, “We (the Steering Council) have not been as strict about following the process as a change of this complexity and reach deserves.” The JIT had been governed only by PEP 744, an Informational-status document by Brandt Bucher and Savannah Ostrowski that the Council judged insufficient for a change of this scope.
• PEP 744 itself records: “Earlier this year, an experimental ‘just-in-time’ compiler was merged into CPython’s main development branch.” That merger happened during the Python 3.13 release cycle, and the code has shipped in every CPython build since while remaining opt-in — the PEP says it “should not be used in production.”
• Fellow Council member Thomas Wouters told The Register the group was not looking to kill the project outright: “We’re not unreasonable, but we do want this taken seriously.”
• Posted to Discourse on July 3 by contributor Ken Jin, PEP 836 — co-authored with Ostrowski and Bucher — lays out a tiered, roughly two-and-a-half-year roadmap keyed to CPython’s release cycle. By the Python 3.16 beta, the JIT combined with the Global Interpreter Lock (GIL) must show a performance uplift of at least 5% over the GIL interpreter alone; by the Python 3.17 beta, the JIT combined with free-threading must show at least a 20% geometric-mean improvement on the pyperformance benchmark suite compared with the free-threading interpreter alone, a bar the PEP treats as the baseline for keeping the project in the CPython tree; and by the Python 3.17 release candidate, the project must also clear compatibility testing against popular PyPI package test suites, with any regressions documented and remediated.
• The PEP spells out its own exit clause: “If these goals are not met, the Steering Council and core team should re-evaluate whether the JIT should remain in CPython main.”
• Beyond performance and compatibility, PEP 836 sets criteria across tooling (preserving native unwinding and frame information used by debuggers and profilers), platform support (all Tier 1 platforms defined under PEP 11), distribution (resolving LLVM dependency issues for redistributors), security (maintaining separation between non-writable and executable code and supporting CET/BTI hardware protections), and maintenance (sustaining a documented, distributed contributor base).
• Early reaction on the PEP 836 discussion thread was mixed but broadly constructive. Core developer Brett Cannon wrote he was “+1 on what the PEP proposes,” while Wouters suggested splitting the criteria from the implementation details and pressed for explicit tracking of startup time, warmup behavior, and memory overhead.
• InfoWorld independently described the document as a roadmap “moving Python’s experimental JIT compiler towards a full-blown, supported, enabled-by-default part of Python’s future,” while cautioning that “the road ahead could be bumpy.”

What We Don’t Know

• Whether the Steering Council will formally accept PEP 836 as written, in a modified form, or reject it — the document remained in Draft status as of its July 3 posting.
• Whether the JIT will actually clear the performance targets on the stated timeline; PEP 836 sets goals but does not guarantee the compiler will meet them.
• How the split Wouters proposed — separating criteria from implementation details — would change the PEP’s substance or timeline if the Council or community adopts it.

Analysis

The dispute is notable less for what it says about the JIT’s benchmark numbers than for what it says about how CPython governs itself. The Steering Council’s complaint was procedural: an Informational PEP was enough to land experimental, opt-in machinery on the main branch back in 2024, but the Council now says a project of the JIT’s “complexity and reach” needs the heavier, standards-track process that PEP 836 attempts to satisfy. That leaves the compiler’s future tied not just to whether it hits its 5% and 20% performance marks, but to whether the wider core-development community — which had already begun picking at the PEP’s structure within days of its posting — converges on an accepted specification before the six-month clock the Council started on June 5 runs out.