By Python’s Steering Council handed its JIT compiler a six-month ultimatum in June: produce a proper, community-approved standards-track PEP, or the JIT gets pulled from CPython’s main branch. For a feature that took years of development and just started delivering real performance gains in Python 3.15, this is a governance problem that could undo a lot of good work — and every Python developer should understand what’s happening and why.
What Went Wrong
The JIT landed in CPython’s main branch in Python 3.13 without following the usual decision-making process. In Python, major changes go through a PEP — a formal proposal that the community discusses and votes to accept. The PEP that covered the JIT, PEP 744, was informational only. It described what the JIT does but didn’t ask for approval, and it left fundamental questions unanswered: who maintains the JIT long-term, how it interacts with free-threading, whether it plays nicely with profilers and debuggers, and what measurable success criteria look like.
That’s not a minor paperwork gap. It’s the kind of process shortcut that creates long-term fragility in an open-source project used by millions of developers who need stability guarantees. The Steering Council was right to call it out.
The Deadline and the Response
On June 5, 2026, the Steering Council froze new JIT development: no new functionality merges into main until a standards-track PEP passes community review. If that doesn’t happen within six months — roughly December 2026 — the JIT code comes out of main and continues as a separate project.
The JIT team responded quickly. On July 2, just four weeks after the freeze, Savannah Ostrowski, Brandt Bucher (the original JIT author), and Ken Jin filed PEP 836, titled “JIT Go Brrr.” The PEP targets Python 3.16 and commits to a 20% performance improvement over the standard interpreter with full tooling compatibility — profilers, debuggers, and coverage tools included. Free-threading interoperability is explicitly on the required deliverables list.
The speed of that response is a good sign. The JIT team isn’t stonewalling; they’re working within the process they should have used from the start.
Where Performance Actually Stands
Here’s the practical picture for Python 3.15. The pyperformance benchmark suite shows:
- x86-64 Linux: 8–9% geometric mean speedup over the standard interpreter
- AArch64 macOS: 12–13% speedup
Python 3.15 also added basic register allocation to the JIT optimizer, which cuts unnecessary stack operations. These are the first Python versions where the JIT is consistently faster — 3.13’s JIT was often slower than the interpreter on real workloads.
The caveat matters: if your application is a Django API waiting on Postgres and Redis 80% of the time, these numbers mean nothing. The JIT helps CPU-bound code — tight loops, numerical computation, hot functions called millions of times. For most web backends, the bottleneck isn’t CPython’s interpreter speed.
How to Try It
Official python.org builds for Windows and macOS ship with the JIT included, disabled by default. Enable it for a single run:
PYTHON_JIT=1 python your_script.pyCheck JIT status from inside Python:
import sys
print(sys._jit.is_available()) # True if this build supports the JIT
print(sys._jit.is_enabled()) # True if the JIT is currently runningDon’t enable it persistently in production yet — it’s opt-in for a reason. But running your own workloads against it now, especially compute-heavy data processing or game logic, gives you a baseline before Python 3.16 raises the stakes.
What’s Actually at Risk
If PEP 836 passes, Python gets a properly maintained JIT with a roadmap to 20%+ gains and compatibility guarantees. If it fails, JIT development moves off-main and loses the momentum, contributor attention, and visibility that comes with being part of CPython proper. Side-branch projects have a poor survival rate in open source.
Mark Shannon, a core CPython developer, raised a legitimate concern: a rushed PEP won’t give the community adequate time for discussion. The six-month clock creates pressure that could produce a PEP optimized for meeting a deadline rather than solving the problem correctly. The Steering Council has signaled some flexibility on the exact timeline — the hard requirement is a proper PEP, not an arbitrary calendar date.
The Bottom Line
The JIT is not going away this week. Python 3.15 ships in the fall with the JIT intact — Beta 4 lands July 18 and the RC opens August 4. The governance issue needs resolution, and the right people are working on it. Watch the PEP 836 discussion thread; that’s where the real decisions get made.
For developers, the action item is simple: understand which workloads would benefit, test with PYTHON_JIT=1 if you have CPU-bound code, and follow the PEP 836 process. Python’s governance exists to protect the language’s long-term stability — and right now, that process is doing its job.
