By Python’s Steering Council handed the JIT team an ultimatum on June 5: produce a proper standards-track PEP within six months, or the JIT compiler gets removed from CPython’s main branch. The JIT has been shipping in official Python binaries since 3.14 and delivers real speedups in 3.15 betas — but it never went through Python’s formal approval process. That procedural gap is now a full-blown governance crisis.
What the JIT Actually Does
CPython’s JIT uses a “copy-and-patch” approach. At build time, LLVM compiles optimized code templates for each micro-op. At runtime, CPython identifies hot execution traces and stitches those templates into executable memory, patching constants and addresses in-place. It builds on the specializing adaptive interpreter introduced in Python 3.11 and extends it beyond the boundaries of individual bytecodes.
In Python 3.15, the JIT got a serious redesign: a new tracing frontend with dual dispatch, basic register allocation, tighter codegen, and around 50% more JIT code coverage than 3.14. Benchmarks from the current betas show 8–9% geometric mean speedup on x86-64 Linux and 12–13% on AArch64 macOS (Apple Silicon and AWS Graviton). Float-heavy compute loops see much larger gains; I/O-bound code sees almost nothing.
The JIT is opt-in. To enable it on Python 3.14 or the 3.15 betas:
# Enable at runtime
PYTHON_JIT=1 python your_script.py
# Check status in code
import sys
print(sys._jit.is_available()) # True if this is a JIT-enabled build
print(sys._jit.is_enabled()) # True if JIT is currently active
print(sys._jit.is_active()) # True if current frame is JITtedThe Process Problem
Here is the issue: the JIT landed in CPython’s main branch without a standards-track PEP. PEP 744 (2024) was purely informational — it described the copy-and-patch design but made zero commitments about maintenance, compatibility with free threading, profiler and debugger integration, or what a “successful JIT” even looks like. In Python’s governance model, that is a significant breach. The PEP process is how Python’s community reaches binding agreements. Skipping it means nobody formally agreed to maintain this feature, handle edge cases, or carry it forward.
The Steering Council’s June 5 announcement was measured but firm: suspend all new JIT development from main, accept only bug and security fixes, and give the team six months to file and get a proper PEP approved. Fail that, and the JIT code comes out.
PEP 836: The Team’s Answer
The JIT contributors — Savannah Ostrowski, Ken Jin, and Brandt Bucher — responded with PEP 836, titled “JIT Go Brrr.” It proposes a path for the JIT to become a formally supported, non-experimental part of CPython if it meets concrete criteria: 4–12% geometric mean improvement on Tier 1 platforms, documented maintenance ownership, and a clear story for profiler and debugger compatibility.
That PEP is now under community discussion, and the clock is running. Mark Shannon, another key JIT contributor, flagged the tension plainly: “A moratorium risks loss of momentum and losing the new contributors we have recently gained.” He is not wrong. Open-source momentum is fragile, and a multi-month freeze while bureaucracy catches up can scatter contributors who were making real progress.
What Actually Gets Affected
The timeline here matters. Python 3.15 hits its final release in October 2026. The Steering Council’s six-month deadline runs until December 2026. If PEP 836 fails, the JIT stays in Python 3.15 as released — it gets removed from 3.16’s development branch. Python 3.13 and 3.14 already shipped; those are unaffected either way.
The practical risk is to Python 3.16 and beyond — the versions where the JIT team planned to push past 20% speedup and start closing the gap with PyPy. That roadmap is now contingent on the PEP process completing successfully. For context, PyPy’s JIT delivers roughly 5–10x faster execution on pure Python loops. CPython’s 8–13% is a first real step, not a destination.
What Developers Should Do Now
If you run compute-heavy Python — numerical simulations, data pipelines, ML inference scripts — the JIT is worth testing today. Enable it with PYTHON_JIT=1, run your actual workload, and benchmark against baseline. The Real Python deep-dive on Python 3.15’s JIT is the best starting point for understanding where you will and will not see gains.
If you rely on profiling tools like cProfile, Py-Spy, or line_profiler, test carefully. JIT interaction with CPython’s profiling hooks can be inconsistent in the current betas. If your application is I/O-bound — web servers, database clients, anything waiting on network or disk — the JIT will not help and is not worth the added complexity right now.
The community can also contribute directly: the PEP 836 discussion thread is actively seeking real-world benchmark results. If you see measurable gains on your workload, sharing those numbers is genuinely useful to the PEP’s case. The Steering Council’s decision will be partly shaped by community evidence.
The Bigger Picture
The Steering Council is right to enforce process. Python’s deliberateness — its insistence that significant changes go through formal community review — is a core reason it remains the dominant language for AI and data work 35 years in. A JIT that ships without documented maintenance commitments or success criteria is technical debt waiting to break something.
But the JIT team is also right that momentum matters. Python’s speed story has improved steadily since 3.11, and the JIT is the centerpiece of that narrative. The right outcome is PEP 836 getting approved, the development freeze lifting, and the team resuming work with formal community backing. The December deadline is aggressive — but achievable if the community shows up to the discussion.
