A 4–12% geometric-mean speedup on pyperformance: that is what CPython's experimental JIT delivered in Python 3.15. The plan to make it a supported feature asked for 20% within two years, and its authors have now withdrawn it. As LWN reported on October 27, 2026, the JIT is set to be removed from CPython's main branch.
What goes and what stays
The JIT compiler landed in main with Python 3.13, using the copy-and-patch design described in PEP 744, and it has always been experimental and opt-in. The official Windows and macOS binaries ship it built but disabled (you turn it on with PYTHON_JIT=1), and distributions such as Fedora and Gentoo do the same. Building it requires LLVM, which moved to LLVM 21 in 3.15.
PEP 836, written by Savannah Ostrowski, Ken Jin and Brandt Bucher on July 2, 2026, laid out a two-and-a-half-year path out of experimental status. Its status is now Withdrawn, dated October 19, 2026. LWN and InfoWorld place the removal early in the Python 3.16 development cycle.
What stays, according to the PEP itself, is the infrastructure the JIT brought into the interpreter: the bytecode DSL and the micro-operations (uops), which make the interpreter easier to maintain with or without a JIT on top.
What it delivered and what was asked
| Result or target | Source | |
|---|---|---|
| JIT in 3.15, Tier 1 (June 2026) | 4.7% (Windows) to 12.6% (macOS M3 Pro) | PEP 836 |
| JIT in 3.15, x86-64 Linux | 7–8% | What's New 3.15 |
| JIT in 3.15, AArch64 macOS | 11–12% | What's New 3.15 |
| Year 1 target (3.16 beta) | ≥ 5% with the GIL | PEP 836 |
| Year 2 target (3.17 beta) | ≥ 20% with free-threading | PEP 836 |
The average hides a wide spread: the 3.15 What's New admits that, depending on the benchmark, the JIT ranged from about 15% slower to more than twice as fast. And the 20% target was not measured against the classic interpreter but against the free-threaded build, which the PEP treated as the main focus. The JIT was not even free-threading safe yet: getting there was a year-one task, with an expected initial cost of 1–2%.
What it means
For anyone running Python in production, the immediate impact is small: hardly anyone had it on, since it had to be enabled explicitly. If you turned it on for a service with PYTHON_JIT=1 on 3.15, that released version does not change; what goes away is the expectation that it would get faster or stable in 3.16 or 3.17.
For the ecosystem, it says a lot about priorities. Without a JIT in the core, CPython's performance gains over the next few years will most likely come from free-threading and the specializing interpreter, not from a JIT in the core. The PEP itself points to JITs that live outside CPython through the PEP 523 interface, such as CinderX and TorchDynamo, and notes that PyPy and GraalPy are faster on some programs, at a cost in extension compatibility, supported versions and tooling.
I think it is the honest call. A JIT in the core makes debuggers, profilers and distributors carry it too; at a 4–12% average with LLVM as a build requirement, the cost for everyone was high. Keeping the work out of main leaves room for it to come back with numbers that justify it.
The open question is whether anyone picks the project up outside the main tree: they would have to clear the same bar to get back in.
Sources
- Python's experimental JIT to be removed, LWN.net, October 27, 2026.
- PEP 836 – JIT Go Brrr: The Path to a Supported JIT Compiler for CPython, Python Enhancement Proposals.
- What's New In Python 3.15, Python documentation.
- Python jettisons the native JIT, at least for now, InfoWorld.