Python JIT removed: CPython drops its speed experiment

Remember when Python was finally going to get fast? Yeah, about that. The Python JIT, the experimental just-in-time compiler that’s been living inside CPython since 3.13, is being pulled out of the main branch. Not paused. Not “deprioritised”. Removed.

And the way it ended is almost more interesting than the JIT itself.

How the Python JIT got voted off the island

Back in June, the Steering Council hit the brakes. No more JIT work in CPython until someone wrote a proper PEP explaining how this thing would become a supported, maintained part of the interpreter instead of a cool science project. Savannah Ostrowski, Ken Jin and Brandt Bucher answered with PEP 836, cheekily titled “JIT Go Brrr”, which laid out a two-year roadmap: switch the frontend from trace recording to a method-based design, make it play nicely with free-threading, and hit at least a 20% speedup on pyperformance by the first beta of Python 3.17.

The council wasn’t buying it. According to the LWN report picked up by InfoWorld, they found the PEP thin on support commitments, on how performance would actually be evaluated, and on integration with debuggers and profilers. They also called it, politely, “overly optimistic” about the gains.

And then came the part that really decides these things. On October 19 the authors withdrew the PEP themselves. Ostrowski’s words: “we don’t feel we have the personal bandwidth to carry the current version forward.” Brett Cannon confirmed what that means in practice: the JIT comes out of main.

The numbers nobody wanted to say out loud

Here’s the uncomfortable bit. After roughly three years of work, the JIT in Python 3.15 was giving a 4 to 12% geometric mean improvement on pyperformance, depending on the machine. Nice on an M3 Pro with tail calls enabled (12.6%). Less nice on a Windows box with a Ryzen 5 (4.7%). And those gains mostly showed up in the kind of code with long, tight, numeric loops, which is precisely the code people already offload to NumPy or Rust anyway.

Meanwhile the adaptive specialising interpreter that landed in 3.11 (the thing that made everyone’s scripts noticeably snappier for free) keeps delivering without any of this complexity. The JIT’s copy-and-patch design was clever, but clever isn’t the same as worth it, and the council basically said so.

I’ll be honest, I’m a bit sad. There’s something romantic about CPython shipping its own JIT rather than conceding that territory to PyPy forever. But the “we don’t have the bandwidth” line is the real story. The people who could do this work are few, the budget for them has been shrinking since the Faster CPython team got gutted, and you can’t maintain a JIT on good vibes and a PEP with a meme in the title. It’s the same tension Linus Torvalds keeps pointing at in the kernel: maintainers, not features, are the scarce resource.

What you should actually do

Nothing, mostly. If you never compiled Python with --enable-experimental-jit (and let’s face it, you didn’t), your Python never had a JIT and nothing changes. If you genuinely need speed, the options are what they’ve been for years: PyPy if your dependencies allow it, Cython or Rust for the hot path, or Meta’s CinderX if you like living dangerously. And the free-threaded build is the thing to watch now, because that’s where the remaining performance energy is clearly going.

The door isn’t welded shut, either. Anyone can fork the work and come back later, but they’ll face the same bar: real maintenance commitments and measurable wins, not projections. Which, frankly, is how it should’ve been from day one.

Python’s JIT went brrr for three years, and the sound it made at the end was a shrug.

Source: InfoWorld — Python jettisons the native JIT, at least for now
Image: Chris Ried / Unsplash