The Python steering council has signaled that the just-in-time compiler project known as Faster CPython could be removed from the main development branch ahead of the 3.14 release. This decision, if finalized, would mark a significant shift in the long-running effort to improve the language’s performance without breaking compatibility with existing code.
The proposal stems from internal discussions about resource allocation and the practical challenges of maintaining experimental code that has not yet delivered the expected speed gains across real-world workloads. According to the article published by The Register, the JIT component has consumed substantial developer time while showing inconsistent results in many common scenarios. Core team members have expressed concern that continuing to carry the code forward might distract from other priorities, including improvements to the type system, better error messages, and enhancements to the standard library.
Python’s reference implementation, CPython, has historically relied on a bytecode interpreter that executes instructions one at a time. This design prioritizes simplicity and portability but comes with a performance cost compared to languages that compile directly to machine code. Over the years, multiple attempts have been made to close this gap. Projects such as PyPy demonstrated that a tracing JIT could deliver substantial speedups for certain workloads, yet it never replaced CPython as the dominant implementation because of compatibility issues with extension modules written in C.
The current JIT effort began in earnest under the leadership of Mark Shannon and later received major contributions from Brandt Bucher and other core developers. The approach chosen for Faster CPython differs from traditional JIT compilers. Instead of tracing hot loops at runtime and generating optimized machine code on the fly, the project introduced a tiered execution model. The interpreter first runs in a specialized bytecode mode that reduces overhead, then promotes frequently executed functions to a second tier that uses actual machine code generated by a relatively simple just-in-time compiler.
This design aimed to provide moderate speed improvements with minimal risk to stability. Early benchmarks showed promising gains on micro-benchmarks and some scientific computing tasks. However, the performance picture became more complicated when applied to larger applications. Web frameworks, data processing pipelines, and GUI programs often exhibited smaller gains or, in some cases, slight regressions due to the additional memory pressure and compilation overhead introduced by the JIT.
The steering council’s potential decision to remove the JIT does not mean the performance work is being abandoned entirely. Much of the infrastructure built for the project, including the specialized interpreter and the tiered execution machinery, has already delivered benefits that will remain in future releases. The removal would primarily affect the code generation component that turns intermediate representation into native instructions. By excising this layer, maintainers hope to reduce the complexity of the codebase and free up time for other improvements that benefit a wider range of users.
Community reaction has been mixed. Some developers who rely on Python for performance-critical tasks worry that giving up on the JIT signals a lack of commitment to speed. Others argue that the language’s strength has always been its readability, vast library collection, and ease of integration rather than raw execution speed. They point out that for many applications, the bottleneck lies in I/O, network calls, or calls into native libraries rather than pure Python code execution.
The discussion also highlights broader questions about how open source language projects should balance innovation with stability. Python’s governance model, refined over the past decade, gives the steering council authority to make hard calls when consensus cannot be reached among the larger group of core developers. This structure has prevented some of the fragmentation seen in other language communities, but it also means that promising experiments sometimes get cut short when they fail to meet practical thresholds.
If the JIT code is removed, the project would not disappear completely. The Faster CPython work lives in a separate GitHub repository where interested contributors can continue experimenting. Some of the ideas may eventually find their way back into CPython through more targeted optimizations. For instance, the specialized bytecode instructions have already proven valuable and are likely to stay. Future releases might also incorporate ideas from other JIT projects or explore static compilation approaches that do not require runtime code generation.
Microsoft has shown particular interest in Python performance because of its heavy use inside Azure and other cloud services. The company has funded several core developers and contributed directly to the JIT effort. Their involvement raises the possibility that a more aggressive JIT implementation could emerge outside the main CPython tree, perhaps as part of a specialized distribution aimed at cloud workloads. Such a move would echo the history of IronPython and other alternative implementations that traded full compatibility for better integration with specific platforms.
Performance remains a persistent topic in Python conferences and online forums. Tools like PyO3, which allows Rust code to be called from Python with minimal overhead, have gained popularity as a way to accelerate critical sections without rewriting entire applications. Similarly, projects that compile Python to WebAssembly or transform it into optimized machine code ahead of time continue to attract attention. These approaches suggest that the community is pursuing multiple paths toward better speed rather than relying on a single solution inside the reference interpreter.
The potential removal of the JIT also reflects practical constraints on the volunteer-driven nature of CPython development. Core developers often balance their work on Python with full-time jobs, family responsibilities, and other open source projects. Maintaining a complex code generation backend requires specialized knowledge of multiple CPU architectures, register allocation strategies, and instruction scheduling. When the returns on that investment appear marginal, it becomes reasonable to question whether the effort should continue within the main distribution.
Looking ahead, Python 3.14 is shaping up to include several notable changes even without the JIT. Work on a new foreign function interface aims to make calling C libraries more efficient and safer. Improvements to the pattern matching syntax and enhancements to data classes could simplify common programming tasks. The ongoing effort to make the language more suitable for static analysis may eventually lead to optional type enforcement at runtime, which could open new optimization opportunities that do not depend on just-in-time compilation.
For package maintainers and library authors, the news carries practical implications. Many projects have begun testing their code against development versions of Python that include the experimental JIT. If the feature is dropped, those testing configurations will need to be updated. However, the compatibility guarantees that Python provides across releases should ensure that existing code continues to run without modification. The removal would primarily affect those who were experimenting with the performance gains rather than those using Python in production today.
The situation also illustrates how expectations around programming language performance have shifted over time. When Python first gained popularity in the late 1990s and early 2000s, its speed was considered acceptable for scripting and glue code. As it moved into scientific computing, machine learning, and web services handling significant traffic, the pressure to improve execution speed increased. Yet the language’s design decisions, particularly the global interpreter lock and dynamic typing, create fundamental challenges that cannot be solved by a JIT alone.
Alternative Python implementations continue to explore different trade-offs. PyPy maintains its own JIT and regularly achieves impressive benchmark scores on pure Python code. GraalPy, built on the GraalVM platform, offers excellent interoperability with other languages and strong performance characteristics. These projects serve as valuable proving grounds for ideas that may later influence CPython. The existence of multiple implementations strengthens the language rather than weakening it, provided they maintain sufficient compatibility with the vast collection of existing Python packages.
The steering council is expected to gather additional feedback before making a final decision. Their process typically involves publishing a detailed PEP or proposal that outlines the reasoning and invites discussion on the python-dev mailing list and Discourse forum. Developers who feel strongly about the JIT’s future are encouraged to provide concrete data about its impact on their workloads rather than general statements about the importance of performance.
Whatever the outcome, the conversation has already produced valuable insights about the current state of Python execution. The specialized interpreter and tiered execution model represent genuine advances in understanding how to make a dynamic language faster without sacrificing its core characteristics. Even if the machine code generation component is set aside for now, the knowledge gained will inform future optimization efforts.
Python’s continued growth depends on balancing the needs of beginners, data scientists, web developers, system administrators, and enterprise users. Performance matters to all these groups, but not to the same degree or in the same way. A solution that delivers modest gains across the board while preserving stability may ultimately prove more valuable than one that provides dramatic improvements for a narrow set of use cases at the cost of increased complexity.
The coming months will reveal whether the JIT experiment has reached its natural conclusion within CPython or whether renewed interest and fresh contributions might yet salvage the feature. For now, the proposal to remove it serves as a reminder that successful open source projects must occasionally make difficult choices about which promising ideas to carry forward and which to set aside in favor of other priorities. The language’s remarkable success over three decades stems in large part from this pragmatic approach to development, and that same pragmatism will likely guide the decision on the JIT’s future.
WebProNews is an iEntry Publication