You’ve been waiting for this moment for years. Every time your Python loop crawls through a million rows, every time you watch your CPU idle while your code chokes on a tight loop — you’ve thought the same thing: When will Python get a real JIT?
Now PEP 836 is here. It promises a path to a supported JIT compiler for CPython. And the initial reaction is euphoria. Faster Python. Near-native speeds. Finally, you can stop feeling guilty every time you write a for-loop.
But stop. Take a breath. Because what’s actually being proposed isn’t a performance miracle — it’s a language trap.
The fastest Python is still Python — but only if it stays adaptable. The real danger of a JIT isn’t that it won’t make things fast. It’s that it will lock the language into an internal representation so rigid that future language evolution becomes impossible.
Here’s the twist: most discussions frame JIT as a pure performance win. You add a compiler backend, you get speed, you move on. But PEP 836’s approach — using copy-and-patch techniques and tiered compilation — forces CPython to commit to a specific intermediate representation (IR). Once that IR is baked into the JIT, changing the bytecode format becomes a nightmare. Every new feature, every experimental bytecode, every extension that touches the interpreter core now has to pass through the JIT’s hoops.
Think about what that means. Want to add pattern matching? Sure, but the JIT’s IR might not support it. Want to optimize generators? Oops, the tiered compiler assumed a certain control flow. Want to introduce experimental garbage collection? Good luck untangling the JIT’s internal hooks.
I’ve seen this play out before in other languages. The JIT becomes a second shadow interpreter, slowly ossifying the language’s core. What starts as a speed upgrade ends as a maintenance anchor.
CPython’s historic strength isn’t speed — it’s simplicity and stability. That’s why we have PyPy, Nuitka, and Cython for the speed-hungry. CPython is the reference, the sandbox, the place where new ideas are tried. Introducing a JIT into that core risks turning the entire Python ecosystem into a brittle monolith.
Yes, the performance gains are real. But ask yourself: is it worth trading Python’s future flexibility for a 2x speedup that most users won’t even notice in their I/O-bound code? Or worse — is it worth making the language harder to extend, just so we don’t have to switch to PyPy?
The path forward should be cautious. If PEP 836 passes, it needs a clear escape hatch: a way to evolve the IR, a commitment to never let the JIT become a blocker for new language features, and a hard limit on the complexity added to the interpreter.
Don’t let the euphoria of speed blind you to the cost of rigidity. Python’s next decade shouldn’t be a decade of incremental maintenance on a frozen bytecode — it should be a decade of bold new ideas. The JIT might make things go brrr, but if it kills the language’s soul, the price is too high.
FAQ
Q: Doesn't a JIT make Python faster? Isn't that good?
A: Yes, a JIT can improve performance, especially for CPU-bound loops. But the question is whether the performance gain outweighs the long-term cost of locking the language's internal representation. CPython's strength has always been its simplicity and ease of extension. A JIT could make future changes harder, slower, and riskier.
Q: So are you saying we should never add a JIT to CPython?
A: Not never — but we should proceed with extreme caution. PEP 836 should include explicit safeguards: a commitment to keep the IR flexible, a clear deprecation path for experiments, and a guarantee that the JIT won't block new features. Speed is valuable, but not at the expense of the language's ability to evolve.
Q: Could this JIT actually be a good thing in disguise?
A: There's a contrarian case: a well-designed JIT might force better discipline in the interpreter, encouraging cleaner bytecode and more consistent semantics. And if it makes Python fast enough for more use cases, it could reduce the fragmentation of the ecosystem (fewer people needing C extensions or PyPy). But the risk remains that the JIT's complexity becomes a barrier to innovation.