We would like to take a moment to talk about the experimental just-in-time compiler in CPython, and the path we think it should take from here.

Over the past several years, several core developers and contributors have been building a JIT compiler in the main branch of CPython. We want to begin by thanking them. This has been hard, deeply technical work that has been done with great care, and the recent performance improvements are real and encouraging. None of what follows is a criticism of that effort or of the people behind it. Quite the opposite. It is precisely because the project has been underway for so long, undergoing several re-architectures, that we think now is a good time to re-evaluate the JIT’s informal status in the project.

When the JIT was originally merged into main, it entered as an experiment, and the only enhancement proposal written about it, PEP 744, is Informational. That PEP did valuable work in explaining the initial design and even sketched the criteria under which the JIT might become a permanent feature, including questions it explicitly left open: committed long-term maintainers, a security review, debugging and out-of-process tooling support, the guarantees the runtime would make, and the obligations the JIT would place on redistributors and downstream packagers. There has also been a fair amount of back and forth over the years, on that PEP and elsewhere, and we acknowledge that a good deal of useful communication has happened along the way. We want to be clear that we are not implying that the authors have intentionally bypassed the formal process. The responsibility is a shared one, ourselves included: collectively we (the Steering Council) have not been as strict about following the process as a change of this complexity and reach deserves. Those open questions in PEP 744 (and more) are exactly the kinds of commitments that the community should weigh and agree to through the PEP process, and they have not yet been settled.

For that reason, the Steering Council is formally requesting a Standards Track PEP be authored that the community can discuss and the Steering Council can formally accept (or reject), making the case for the JIT as a supported, non-experimental part of CPython: its guarantees, its maintenance commitments, and its impact on redistributors.

Until such a PEP is accepted, we ask that no new development on the JIT land on main, including new features, optimizations, and performance work. Bugfixes and security fixes may of course continue as normal; the request is specifically that no further new JIT functionality be added until a PEP has been accepted.

While the intent is not to call for competing proposals, we believe that now is a good time to discuss and propose alternative proposals as well. We believe this approach is also consistent with our previous long-standing view that experiments should not be done on the main branch of CPython without a backing PEP.

For example, rather than proposing one single concrete JIT implementation, it may make more sense for the PEP to describe a JIT infrastructure that can support multiple implementation strategies. Since many different and promising JIT tracing approaches continue to be proposed, we believe the infrastructure should make it easy to experiment with and evaluate those approaches within CPython rather than be highly coupled with a single strategy.

We would like the PEP to address at least the following points:

• Maintenance is a real concern for a subsystem of this size and complexity, and the PEP should set out a clear plan for how the JIT will be sustained and maintained over the long term and how it will impact maintainers and contributors that don’t directly contribute to the JIT.

• How it will keep compatibility with existing CPython features and tooling. How the JIT interacts with, and what it guarantees for, the capabilities CPython already supports. This includes things such as free-threading, profilers, and debuggers, but the PEP should treat this broadly and with nuance rather than as a fixed checklist.

• Clear, measurable success metrics and timelines. What the project is aiming for and by when, for example performance targets, platform coverage, and memory overhead.

• Relationship to other JIT compilers. Whether the design is intended to provide general infrastructure that other efforts could build on, and whether it is expected to be compatible or incompatible with third-party JIT implementations such as CinderX, Numba, and PyTorch or any other 3rd party JIT.

• Whether the current JIT architecture is considered stable, or likely to change further.

This list is not exhaustive. It is meant to be indicative of the kinds of questions we want the PEP to engage with, and we expect further points to be added as the community discussion evolves.

We are setting a window of six months for a PEP to be submitted and resolved. If no such PEP is accepted within that window, the JIT code must be removed from the main branch and development must be continued outside the main Python repository.

We know this asks something of the people who have invested years in this work, and we don’t take that lightly. We see this not as winding the project down but as giving it, and the community, the clarity and the explicit commitment that a change of this magnitude to CPython’s runtime deserves.

Thank you for your understanding, and for everything you’ve built so far.

— The Python Steering Council