By ByteBot
The Python Steering Council froze all new JIT development in June 2026 and gave the project six months: produce an accepted standards-track PEP, or the JIT code gets pulled from CPython’s main branch. This is not a procedural technicality. It puts Python’s flagship performance feature for the October 2026 release in genuine limbo — and the Steering Council’s own admission is that they let it happen.
The Governance Gap No One Wanted to Admit
CPython’s JIT has lived in main since Python 3.13 under PEP 744 — an informational PEP. Not a standards-track PEP. Not a formal acceptance decision by the community. Just documentation. The distinction matters because an informational PEP cannot bind the Steering Council or the contributor community to anything. There are no maintenance commitments, no success metrics, no defined compatibility guarantees.
Steering Council member Pablo Galindo Salgado put it plainly: “For such a complex and far-reaching change, we (the Steering Council) did not have strict control over the process implementation.” That is a significant admission from a governance body that prides itself on Python’s deliberate development culture. The JIT shipped, improved, became a headline feature of Python 3.15 — and the formal governance backing was never there.
The freeze covers everything except bug fixes and security patches. No new optimizations, no new features, nothing that advances the JIT’s capabilities. This matters because the JIT team was mid-stride: Python 3.15 beta shows 8-9% geometric mean improvement on x86-64 Linux and 12-13% on Apple Silicon — real numbers, after years of disappointing early results. Now development stops until the paperwork catches up.
What PEP 836 Must Prove
The team’s response is PEP 836, titled “JIT Go Brrr.” It proposes a 2.5-year roadmap with explicit milestones. For Python 3.16: transition from trace recording to method-based compilation, full free-threading compatibility, improved support for profilers and debuggers, and a minimum 5% performance uplift maintained. For Python 3.17: a 20% geometric mean improvement on the pyperformance benchmark suite — JIT plus free-threading combined, compared to the free-threading interpreter alone.
If the JIT misses those targets, or if no PEP gets accepted by roughly December 2026, the code comes out of main. External development could continue, but CPython users would see no JIT until a future version reintroduced it through proper channels.
Brett Cannon, a Python core developer, expressed support: “The 20% performance goal for 3.17 along with making sure the JIT works with free-threading makes me a +1 on what the PEP proposes.” Thomas Wouters wants the PEP split in two — one for acceptance criteria, one for the implementation pathway — arguing the current draft conflates distinct decisions. The community discussion is live on the Python Discourse forum.
The Awkward Bind Shannon Predicted
JIT lead contributor Mark Shannon described the problem with unusual directness. “Stopping all development until a PEP is accepted puts us in an awkward position,” he said. “A moratorium risks loss of momentum and losing the new contributors we have recently gained.” He asked for a grace period of a month or two. The Steering Council did not grant it.
Shannon is pointing at a genuine tension: a rushed PEP will not get the community deliberation it deserves, but a slow PEP means months of frozen development on the eve of Python 3.15’s October release. The Steering Council’s answer is essentially: that tension is the cost of not following process the first time. They are not wrong. But the JIT team is paying the price for a governance decision that the council admits was partly their own lapse.
What This Means for Developers
For most Python developers, the practical impact right now is zero. The JIT is disabled by default and must be explicitly enabled at build time. Nothing in Python 3.15 changes that. The performance numbers ByteIota covered in our earlier JIT benchmark guide still apply — you just cannot expect further improvements on that trajectory until PEP 836 is accepted.
The question worth watching is whether the freeze affects the October release. Python 3.15 ships on schedule, JIT included, still experimental. But the team cannot fix JIT-specific performance regressions discovered in beta unless they qualify as bugs. That is a narrower runway than the project had two months ago.
Also worth noting: third-party JITs — Numba, CinderX, TorchDynamo — are entirely unaffected. CPython’s JIT and these tools operate at different layers. If your team runs PyTorch or uses Numba for numerical work, the Steering Council dispute does not touch you.
The Bottom Line
The Steering Council is correct that a flagship feature with no formal maintenance commitment, no success metrics, and no governance backing is a problem waiting to happen. PEP 744 being informational was always a placeholder, not a plan. PEP 836 is the real plan — but it arrived under pressure, and pressure-cooked PEPs sometimes have problems the community only finds after the vote.
EuroPython’s Language Summit in Kraków is today (July 14). The JIT’s fate is almost certainly on the agenda. If PEP 836 gets traction there, the clock gets easier. If it runs into structural objections — like Thomas Wouters’s argument that it is two PEPs pretending to be one — the six-month deadline gets tighter. Either way, the Python community’s ability to govern its own performance story is being tested in a very public way. Follow the Steering Council thread and PEP 836 to track where it lands.
