Python JIT development was urgently halted by officials: the PEP needs to be revised and resubmitted within six months, otherwise the relevant code will be completely removed from the main branch

The Python community is experiencing an uncommon "internal braking" event.

Recently, the Python Steering Council suddenly issued an announcement titled "Regarding the JIT Project", requiring a suspension of all new feature development work on the Just-In-Time (JIT) compiler project in the main code branch. Existing code can continue to have bugs fixed and security updates, while all new features, new optimizations, and performance iterations are put on hold.

The council also set a clear time limit: within the next six months, core developers and contributors responsible for JIT development must submit a formal PEP proposal; if not submitted on time, the JIT code will be completely removed from the main branch.

This announcement surprised many developers. After all, the JIT compiler project being advanced in CPython was originally an important part of the Python 3.13/3.15 performance roadmap, and it had already brought about an approximately 8 - 9% geometric mean performance improvement (x86 - 64 Linux). Why did it stop all of a sudden?

From "Experimental Feature" to "Governance Dispute"

In fact, the built - in JIT in Python has been a key focus of core performance optimization in recent years, and as mentioned above, it has achieved tangible performance improvements.

However, Python's JIT was not initially designed as an official feature.

It initially entered the CPython main branch as an "experimental feature", corresponding to PEP 744. However, this is only an Informational PEP (informational proposal) and does not complete the full governance cycle required for a standard feature.

In addition, this PEP itself also clearly left a bunch of "unresolved issues", including key issues such as whether there is a long - term maintenance team, security review, debugging and toolchain support, impact on distributions and downstream, and runtime guarantee boundaries. Over the years, a unified community standard has never been formed.

Pablo Galindo Salgado, a member of the Python Steering Council, also admitted in an article that the previous supervision was lax, allowing a core feature of high complexity to remain in an informal experimental state for a long time. He said: "For such a complex and far - reaching change, we (the Steering Council) did not have strict control over the process implementation."

Reserving Six Months for JIT Core Developers to Rewrite the PEP

Therefore, members of the Python Steering Council require core developers and contributors of the JIT compiler to rewrite a formal PEP to clarify the official positioning, maintenance mechanism, ecological impact, and compatibility standards of JIT for community discussion. The Steering Council will formally accept or reject it after evaluation.

At the same time, the Python Council also suggests that core developers of the JIT compiler open up new ideas: do not be limited to the existing single JIT solution, and can build a general JIT infrastructure to support iterative testing of multiple optimization strategies.

In addition, the official clearly states that the latest version of the PEP proposal should at least solve the following problems:

Especially for a subsystem of this scale and complexity, maintenance is indeed a real problem. Therefore, this PEP should clearly state how JIT will be continuously supported and maintained in the long term, and how it will affect maintainers and contributors who are not directly involved in JIT development.

It also needs to explain how JIT will be compatible with existing CPython features and tools. For example, how JIT will work in conjunction with the existing capabilities of CPython and what guarantees it will provide for these capabilities. This includes things like free - threading, performance profilers, and debuggers, but the PEP should handle these issues in a more extensive and detailed way, rather than simply treating them as a fixed checklist.

In addition, clear and measurable success indicators and time plans need to be provided. That is, what goals this project is going to achieve and when, such as specific indicators in terms of performance goals, platform coverage, and memory overhead.

Another important issue is its relationship with other JIT compilers. It needs to be explained whether the design aims to provide a general infrastructure for other projects to build on; and whether it is expected to be compatible or incompatible with third - party JIT implementations, such as CinderX, Numba, PyTorch, or any other third - party JIT.

It also needs to be clarified whether the current JIT architecture is considered a stable design or is still likely to change.

Moreover, Pablo Galindo Salgado further stated, "The above list is not exhaustive. It is just an indication of the types of issues we hope the PEP can cover. As the community discussion progresses, we also expect to further add new concerns."

Community Dispute: Core Developers Oppose the Freeze, but There Are Also Voices of Approval

Facing this policy change, there is an obvious divide in the Python community.

According to foreign media The Register, Mark Shannon, a core JIT developer, believes that "Halting all development before the new PEP is approved puts us in a dilemma."

Because this will force the JIT team to rush to formulate a new proposal without giving the community enough time for discussion. He revealed that the team originally planned to launch a new proposal later this year, when the performance improvement effect of the compiler would be more significant.

In addition, Mark Shannon has applied for a grace period of one or two months to continue the development. He said, "Suspending development may cause the project to lose momentum and result in the loss of new contributors we have attracted recently."

When asked whether development could continue in a branch repository, Mark Shannon said it was not feasible - due to the special generation mechanism of the optimized code, the code difference between the branch and the main branch would be extremely large, making it difficult to maintain and manage.

On the other hand, some developers believe that the decision of the Python Council is reasonable: JIT is no longer a "small experiment". If it is to become a core component of CPython in the future, it must follow the standard PEP; otherwise, it will undermine Python's consistent "governance consistency".

Conclusion

This rectification means that the Python official has completely tightened the rules for experimental features in the main branch, ending the years - long iterative mode of JIT of "trying while doing without formal specifications". The upgrade of core functions has fully returned to the standardized community consensus mechanism.

Pablo Galindo Salgado, a member of the Python Council, also explained, "We are not trying to terminate this project, but to provide clear explanations and clear commitments for the project itself and the community to deal with such a major change in the CPython runtime."

However, in reality, this decision of the Steering Council has cast a shadow over the future of the JIT project. Previously, the project was almost certain to become an official part of CPython, but now there are many more uncertainties. It is already very tight to complete a PEP proposal and reach a consensus within six months; once the JIT code is really removed from the main branch, the development pace of the project will slow down significantly.

What do you think of this?

References:

https://www.theregister.com/devops/2026/06/08/python-jit-compiler-may-be-removed/5252079

https://discuss.python.org/t/an-announcement-from-the-steering-council-regarding-the-jit-project/107638

This article is from the WeChat official account "CSDN". Compiled by Tu Min. Republished by 36Kr with authorization.