Python's JIT Is Getting Ripped Out of CPython. Here's What Actually Went Wrong

The Python JIT is being removed from CPython. It's #4 on Hacker News right now with 270+ comments, and half of them are wrong about why.

Let's fix that.

What happened

Short version, per LWN's coverage:

• 2024: Brandt Bucher's copy-and-patch JIT lands in CPython 3.13. Experimental, off by default, justified by an informational PEP (PEP 744).
• June 2026: The Steering Council pauses JIT work in main. New rule: write a standards-track PEP or the code comes out. Roughly six months on the clock. (The Register's take)
• July 3: PEP 836, "JIT Go Brrr: The Path to a Supported JIT Compiler for CPython", goes up for feedback. Authors: Brandt Bucher, Savannah Ostrowski, Ken Jin.
• September 21: Council responds. The PEP "mostly answers the questions we asked," but wants more on several points.
• October 19: The authors withdraw PEP 836.
• Next: JIT removal from main, expected early in the 3.16 cycle.

Savannah Ostrowski's withdrawal note is the line to read: "The Steering Council rightly sets a high bar for a proposal of this scope, and we don't feel we have the personal bandwidth to carry the current version forward."

Read that again. Not "the JIT doesn't work." Bandwidth.

The JIT wasn't a failure. The process was.

Here's the part the hot takes miss. By the PEP's own numbers, the JIT in 3.15 delivers roughly a 4-12% geometric mean speedup across Tier 1 platforms. That's not nothing. It's also not the "Python is fast now" headline people wanted in 2024.

The Council's objections weren't about speed:

1. No unified design. Experimenting in main leaves core devs, package maintainers and users guessing what will change next.
2. Maintenance and support commitments were undefined.
3. Security was, in the Council's words, "an underserved area in the PEP." They wanted the security response team involved.
4. Platform parity. Worry that the design could end up tied to specific platforms.
5. A compatibility review scheduled for August 2028 was called "way, way too late."

That's a governance review, not a benchmark review. And honestly? They have a point. An informational PEP is a description, not a contract. You can't ship a JIT that touches every C extension, debugger and profiler in the ecosystem on a handshake.

Why it was always going to be hard

One LWN commenter nailed it: writing a proper JIT for Python is incredibly hard, and the gains are pretty small.

Why small? Because CPython's dynamism and C-API surface area are the product. Every sys.settrace, every extension that pokes at frame internals, every monkeypatch is a constraint on what a JIT may assume. PyPy has had a world-class JIT for years and still lags on version support and extension compatibility. That's the tax.

A copy-and-patch JIT is the cheap-to-maintain end of the design space. It still wasn't cheap enough to survive without a funded owner and a written plan.

What this means for your code

Almost nothing, today. The JIT was never on by default. If you've never touched it, nothing changes.

If you were experimenting, this is how you opted in:

# build from source
./configure --enable-experimental-jit
make -j

# or, on builds that ship it
PYTHON_JIT=1 python my_script.py

Don't build production plans on it. Cheap check before you bother: benchmark honestly, with the JIT on and off.

# bench.py
import time

def hot(n):
    total = 0
    for i in range(n):
        total += i * i % 7
    return total

hot(10_000)  # warm up
t = time.perf_counter()
hot(20_000_000)
print(f"{time.perf_counter() - t:.2f}s")

python bench.py
PYTHON_JIT=1 python bench.py

If you see single-digit-percent gains on your real workload, that's the entire story of this feature in one terminal window.

Where speed actually comes from now

If you need Python to be fast, you were never going to wait on CPython's JIT:

• Numba / PyTorch compile: JIT the numeric hot path, not the whole language.
• Free-threaded Python: real parallelism instead of a faster single thread. The JIT authors say they're still optimistic about free-threaded support.
• PyPy: still the answer for long-running pure-Python workloads, if your dependencies cooperate.
• CinderX: Meta's external JIT, living outside core.
• Rust/C extensions for the genuinely hot loop. Still the boring winner.

My take

The Steering Council made the right call procedurally and a painful one practically.

Right, because "merge it experimental and sort it out later" doesn't scale when the thing you're merging is a compiler. Painful, because the people who built it did the work in public, on volunteer and sponsor time, and the project's answer was "write a bigger document, find more time."

The lesson isn't "Python can't have a JIT." It's that core performance work needs a funded owner, a written contract, and a security story before the first line lands in main, not after.

Brett Cannon confirmed the work stops in the main repo but can continue in the community. That's the real next chapter. Watch for a fork or an out-of-tree project that picks up the copy-and-patch approach. It's not dead. It's just homeless.

One more commenter's line is worth keeping: everyone acted in good faith, and a process problem was acknowledged and addressed without acrimony. In open source, that's rarer than a 12% speedup.

Sources: LWN: Python's experimental JIT to be removed · PEP 836 · The Register · HN thread

Are you using the JIT anywhere? Tell me what you measured.