Python's Experimental JIT Removed: The Reasoning Behind the Technical Decision

Background

According to a report from LWN.net, the Python core development team has decided to remove the experimental JIT (Just-In-Time compilation) feature. The news sparked widespread discussion in the technical community, with the related Hacker News thread garnering 304 points and 153 comments, demonstrating developers' strong interest in the direction of Python's performance evolution.

JIT compilation technology has long been regarded as a key path to performance breakthroughs for dynamic languages. As one of the most popular programming languages, Python's interpreted execution model has inherent bottlenecks in compute-intensive scenarios. The experimental JIT project once carried the community's hopes for order-of-magnitude performance gains, but ultimately did not make it into an official release.

JIT (Just-In-Time compilation) is a compilation strategy that dynamically compiles hot code into machine code at program runtime, as opposed to traditional ahead-of-time (AOT) compilation. Its core idea is: the interpreter first runs bytecode with low overhead while collecting runtime information such as types and execution frequency, then optimizes and compiles repeatedly executed hot paths—thereby approaching statically compiled performance while preserving the flexibility of dynamic languages. Java's HotSpot, JavaScript's V8, and PyPy all follow this approach. For Python, the difficulty of JIT lies in CPython's highly dynamic object model, the difficulty of type inference, and the fact that the C extension ecosystem widely depends on interpreter internals—any JIT must be compatible with these existing conventions, which is precisely an important reason why experimental projects struggle to land.

The Technical Logic Behind the Removal Decision

Removing the experimental JIT is not a rejection of the importance of performance optimization, but rather reflects realistic trade-offs in language evolution. A JIT compiler needs deep integration with the CPython interpreter, involving multiple subsystems such as bytecode generation, type inference, and memory management. Maintaining such a complex component requires sustained investment of core developer resources, while the experimental branch remained detached from mainline development for a long time, with merge costs continuously accumulating.

From an engineering perspective, a JIT that cannot be stably delivered actually distracts the community. Python's alternative performance solutions—including C extensions, Cython, and the subinterpreters that have emerged in recent years—already provide viable paths in different scenarios. Removing the experimental JIT can be seen as a focus on the technical roadmap rather than an abandonment of performance goals.

Subinterpreters are an important capability that CPython has advanced in recent years, allowing multiple isolated Python interpreter instances to run within the same process, each with its own independent Global Interpreter Lock (GIL) state. One of its goals is to achieve true parallel execution without breaking compatibility with existing C extensions, and it is regarded as one of the viable paths around GIL limitations. C extensions and Cython, in parallel, represent another line of thinking: pushing performance-sensitive code down to the compiled-language level, with developers explicitly bearing the responsibility for optimization. Together, these solutions constitute Python's current performance strategy of "multiple approaches blooming, gradual improvement," which also explains why the core team prefers to concentrate resources rather than maintain a JIT branch that cannot be merged into the mainline for a long time.

Community Reaction and Controversy

The Hacker News discussion showed clear divisions. Some developers consider this a pragmatic move, avoiding wasting scarce core development bandwidth on immature technology; others worry that Python will fall further behind emerging languages in the performance race.

This division touches on a long-standing tension in the Python community: the balance between maintainability and performance ambition. CPython's status as the reference implementation means its decisions must prioritize stability and backward compatibility, which creates a structural contradiction with the experimental spirit of pursuing extreme performance.

CPython is the reference implementation of the Python language, maintained by the core development team, and its behavior defines the de facto standard of the language specification. This status brings a structural constraint: any feature entering the mainline must guarantee cross-platform stability, backward compatibility, and long-term maintainability, because downstream distributions, frameworks, and tens of thousands of third-party libraries use it as their benchmark. By contrast, alternative implementations such as PyPy can more aggressively experiment with performance technologies like JIT, but they have long-standing shortcomings in C extension compatibility. Understanding this division of labor helps explain why performance experiments often occur outside the reference implementation, and why the core team is cautious about merging such experiments.

Impact on the Python Ecosystem

In the short term, removing the experimental JIT has no direct impact on the vast majority of Python users, since the feature never entered a stable release. The long-term impact is reflected at the level of ecosystem confidence: performance-sensitive projects may need to more actively evaluate alternatives, and the signal sent by the core language team is that Python's performance improvements will follow a gradual, maintainable path.

For teams that rely on Python to build high-throughput services, this event reminds us to focus on the maturity of the performance optimization toolchain rather than waiting for a silver bullet at the language level.

Conclusion

The removal of the experimental JIT is a course correction in Python's evolution. It reveals the eternal game between innovation and stability in a mature language, and also provides a typical case for observing the technical decision-making mechanisms of open-source projects.