Python's most-hyped performance feature just got a reality check from the people who run the language. The Steering Council has effectively put the experimental just-in-time (JIT) compiler on notice: prove it delivers real, consistent speedups, or face removal. After years of "faster CPython" momentum, an ultimatum aimed at a flagship feature is a notable shift in tone, and a healthy one. It signals that CPython's maintainers will not carry a large, complex subsystem indefinitely on the promise of future gains.

  • The ultimatum. The Steering Council set a bar and a deadline for the JIT to demonstrate its value, rather than letting it live on as a permanent experiment.
  • The tech. CPython's JIT uses a copy-and-patch design, stitching together precompiled machine-code templates for hot code paths at runtime.
  • The problem. Real-world speedups have been modest and inconsistent, and the JIT adds build complexity and maintenance burden.
  • The context. It lands alongside 3.15 betas and the free-threading push, as CPython juggles several ambitious performance bets at once.
How CPython's JIT fits in Python source becomes bytecode, a tier-two optimizer traces hot paths, and the copy-and-patch JIT emits machine code, with a decision gate on whether it earns its keep. bytecode tier-2 tracehot paths copy-and-patch JITmachine code faster run?must prove it deadline: earn your keep The JIT is real engineering. The question is whether the payoff justifies the upkeep. genztech.blog
Fig 1 The JIT sits at the end of CPython's optimization pipeline, turning hot traces into machine code. The Steering Council wants proof that step is worth its weight.

What did the Steering Council actually decide?

Rather than quietly keeping the JIT as a permanent optional experiment, the Council attached a condition to its continued existence: it needs to demonstrate meaningful, reliable performance improvements within a defined window, or its place in CPython is not guaranteed. This is unusual. Big CPython features are usually nurtured for years on the strength of their direction. Putting a formal bar in front of the JIT reframes it from "the future of Python speed" to "a bet that now has to pay off." The message to contributors is that maintainer time and build complexity are finite resources, and a feature that ships in every release has to justify that cost with numbers.

RelatedFlutter 3.44 adds agentic hot reload and GenUI

How does the copy-and-patch JIT work?

CPython's JIT uses a technique called copy-and-patch. Instead of building a heavyweight compiler that generates machine code from scratch, the build process precompiles small templates of machine code for common bytecode operations. At runtime, when the interpreter detects a hot path through a tier-two optimizer, it stitches those templates together and patches in the specific values, producing native code quickly and cheaply. The appeal is elegance and low complexity relative to a traditional optimizing JIT. The catch is that copy-and-patch trades some peak performance for that simplicity, so the speedups tend to be real but modest, and they vary a lot depending on the workload.

Why is the payoff so inconsistent?

Python programs spend much of their time in C-implemented built-ins, libraries, and I/O, not in the pure-Python loops a JIT accelerates most. So a benchmark heavy on tight numeric loops might show a nice gain, while a typical web service or data script barely moves, because the hot path was never in interpreted bytecode to begin with. Add the maintenance surface, the build-system complexity, and the fact that the JIT competes for engineering attention with free-threading and other faster-CPython work, and you get the Council's dilemma: a technically impressive feature whose average real-world benefit has been hard to demonstrate. An ultimatum forces the question into the open with data instead of vibes.

What does it mean for Python developers?

For most developers, nothing breaks today. The JIT remains an opt-in, off-by-default experiment, and 3.15 continues through its beta cycle regardless. But the decision matters for how you should think about Python performance. Do not architect around a JIT that may not survive, and do not expect free speedups from it on typical workloads. The more durable performance stories in CPython right now are free-threading, which removes the GIL for genuine parallelism, and the steady interpreter optimizations that benefit everyone with no flags. If your code is CPU-bound in pure Python, the reliable moves remain the familiar ones: profile first, push hot loops into C extensions or vectorized libraries, and use the right data structures, rather than waiting on a JIT to rescue you.

RelatedMicrosoft Ships Agent Framework 1.0 for .NET and Python

What to watch · 2026
  • The benchmark verdict. Whether the JIT team can post consistent, defensible speedups by the deadline.
  • Free-threading momentum. If the no-GIL work becomes the headline performance story instead.
  • Build complexity. Whether maintainers decide the upkeep is worth it even at modest gains.
  • 3.15 release. How the JIT is positioned when 3.15 ships this fall.

Our take

This is CPython governance working exactly as it should. A JIT compiler is genuinely cool engineering, and copy-and-patch was a smart, pragmatic way to add one without a monstrous new codebase. But "cool" is not the bar for a feature shipped to millions of users, and the Steering Council is right to demand that the payoff be measurable rather than perpetually promised. If the JIT can prove consistent wins, great, it earns its place. If it cannot, cutting it frees maintainer energy for free-threading, which is the more transformational bet. Either outcome is better than the status quo of a permanent experiment that everyone assumes is the future. Deadlines force clarity, and Python's performance roadmap is healthier for having one.

Primary sources

Original analysis by GenZTech. Reporting via Real Python.