Python's experimental JIT to be removed

Python's experimental JIT to be removed [LWN subscriber-only content] Welcome to LWN.net The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider subscribing to LWN. Thank you for visiting LWN.net! Welcome to LWN.net The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider subscribing to LWN. Thank you for visiting LWN.net! Python's experimental just-in-time (JIT) compiler, which was added to CPython in 2024 for the 3.13 release, is on its way out. In June, the Python steering council announced that it was pausing work on the JIT in CPython's main branch until there was an accepted Python Enhancement Proposal (PEP) that addressed concerns about maintenance, compatibility, and set clear success metrics as well as a timeline for completion. After creating PEP 836 ("JIT Go Brrr: The Path to a Supported JIT Compiler for CPython") to try to meet the council's request, and after months of discussion, the JIT maintainers have withdrawn the PEP. For now, it appears that development on the once-promising project has come to an end. The JIT was added to CPython by Brandt Bucher in early 2024. Generally, such a major feature would be expected to land only after the council had approved a standards-track PEP. Bucher had given a talk (YouTube video, slides) about the JIT at a Python core developer sprint, and announced his intent to merge the feature—but he had not taken the step of authoring or submitting a PEP for its approval. He was prodded into doing so by steering council member Thomas Wouters, who was also serving as the release manager for Python 3.13. Bucher and Savannah Ostrowski drafted PEP 744 ("JIT Compilation"), which was an informational PEP—meaning it only provides information to the Python community and does not represent formal consensus to proceed on a feature or project. LWN covered the discussion of PEP 744 in April 2024, and later covered Bucher's talk on the JIT at PyCon US 2024, as well as the follow-up talk at PyCon US 2025. PEP it up Work on the JIT had been proceeding on the basis of PEP 744 until this June, when the council had put forward its formal request for the JIT maintainers to create a standards-track PEP. One might wonder, as Antoine Pitrou did, why the council had decided that it was time to speak up and ask for a new PEP. Wouters said that there was no "single triggering event for this request", but that the council had been discussing the topic for a while and indicated that it was looking to ensure the JIT work did not interfere with other projects. "There's been work trying to get the JIT to play nice with instrumentation, debugging, and profiling. There's also external JITs (like CinderX), JIT-adjacent things (like Numba and PyTorch's compile), and discussions about a tier 3 JIT." The council had waited until after the Python 3.15 beta release "to be clear that we're OK with the status quo for 3.15". The council asked for a PEP that would make the case for the JIT "as a supported, non-experimental part of CPython: its guarantees, its maintenance commitments, and its impact on redistributors". The council set a deadline of six months for the PEP to be submitted and accepted; failing that, the council would require the JIT code to be removed from the CPython main branch. Bucher, Ostrowski, and Ken Jin drafted PEP 836 and published it on the Python forum for community feedback on July 3. It generated quite a bit of discussion, some favorable and some critical. One of the key themes in the comments, such as this one by Wouters, and this comment by Mark Shannon, was that the draft felt like it should be two separate PEPs. Shannon, for example, thought that the PEP should only cover goals for accepting the JIT work and felt that it should leave out implementation details. There were also quite a few calls for additional information. Bucher pushed back a bit on the suggestion that it should be two PEPs, and Ostrowski defended the structure of the PEP as it was. "Outlining goals like we have in the PEP without being able to share the plan and everything we've thought through alongside it would make me uncomfortable. To me, goals without plans behind them aren't really goals at all." When we last looked at this topic in September, the discussion about the PEP had slowed down without a commitment to develop new PEPs or a formal statement from the council. The last word from the council at that time, in the form of a summary of its August 6 meeting, was that it had met with the PEP authors and was "discussing the state of the PEP and whether it answered the questions the SC asked in its request for a PEP". Experimentation in main On September 21, Wouters posted a statement from the steering council, minus Ostrowski (who is currently a member of the steering council but did not participate since she is a co-author of the PEP), that summarized its position. The statement said that PEP did answer all of the questions that were highlighted in the council's request, "although perhaps some less convincingly than others". The council wished to make clear that it was not looking for the criteria that the JIT should meet to be a supported feature, or whether it should be considered such. Instead, the council was evaluating whether the JIT should continue as an experiment in CPython's main branch. Part of the problem with allowing experimentation in main is the lack of unified design, and the uncertainty that core developers, package maintainers and users face as the experimentation changes behaviours and API surfaces. The council said that the PEP was not specific enough about support plans, performance criteria, and too vague or too optimistic about a number of other areas. The statement included a ten-point list of items that the council wanted "to see either spelled out in the PEP, or at least discussed and rejected". The council's list expressed concerns ranging from memory impact to security. For example, on the topic of platform parity, the council wanted to ensure that the JIT was designed to be easily adopted for new platforms. It wanted assurance that the JIT's design would not be tied to specific platform or require platform-specific knowledge to maintain. Another area that the council called out was user impact. It said that the PEP was "overly optimistic" about user-visible differences with the JIT enabled. There were many cases where users depend on idiosyncrasies in the interpreter design, "as we've seen with other Python implementations or even just between major Python versions", and it wanted clarification on how those differences would be handled. Would they be considered bugs, how would situations be handled if a difference in behavior was unavoidable, and so on. Security was "an underserved area in the PEP", according to the council; it suggested that a discussion with the Python security response team was in order and that a security review should be part of the criteria for supported status as well. PEP 836 specified a compatibility review milestone to correspond with the first Python 3.17 release candidate—which would be expected sometime in August 2028—that would involve running the test suites of the top PyPI packages to see if the JIT broke them. The council wanted that timeline moved up significantly. "We think that's way, way too late, and the compatibility review should be an ongoing and continuous process starting as soon as possible". The council also worried about the JIT's design decisions being made "without critical review by the larger group of developers ultimately responsible for [CPython] development, maintenance and support". The bottom line, it said, was that PEP 836 "mostly answers the questions we asked" with no missing pieces, but it wanted more discussion on those topics so it could "gauge community support and consensus before we're asked to pronounce on this PEP". Jin replied a few days later to thank the council for its detailed feedback and said that the group would work on its suggestions. Withdrawn After some consideration, it appears, the PEP's authors have decided not to continue pursing the council's approval. On October 19, Ostrowski (who is also release manager for Python 3.16 and 3.17) announced that the PEP was being withdrawn: The Steering Council rightly sets a high bar for a proposal of this scope, and we don't feel we have the personal bandwidth to carry the current version forward. We continue to believe in the technical direction outlined in the PEP, including free-threaded support and a method-based frontend, and remain optimistic about the JIT's potential in CPython. We'll make the reference implementation available and link it from the withdrawn PEP so others who are interested can explore and build on that. Barry Scott asked if that meant that work on the JIT was stopped. Brett Cannon replied that the work would be stopped in the main repository, but it would be up to the community whether the work would continue elsewhere. Dunc Graham suggested that there might be time for an alternative PEP to be submitted before the council's deadline. Cannon said that was not likely, "as all the people actively driving the JIT were either authors on that PEP or contributors to it". With the PEP withdrawn, the JIT will likely be removed from CPython main fairly soon to ensure that any problems caused by its removal can be addressed early in the Python 3.16 development cycle. It is unclear whether the original drivers of the JIT work intend to continue working on it at all, or if it will simply be left for others to pick up if there is enough community interest. I have emailed the PEP authors for clarification, but have not yet received a reply. Seems civil Posted Oct 26, 2026 20:00 UTC (Mon) by jkingweb (subscriber, #113039) [Link] (2 responses) Hopefully this won't be the end of the work, because Python can always benefit from better performance. Seems civil Posted Oct 26, 2026 21:54 UTC (Mon) by ballombe (subscriber, #9523) [Link] (1 responses) Seems civil Posted Oct 27, 2026 1:53 UTC (Tue) by acarno (subscriber, #123476) [Link] For one thing, pypy only suppports Python 3.12, 3.11 and 2.7. More significantly, pypy isn't CPython - it's an alternative implementation that is mostly compatible but with a few noticeable differences (the pypy website lists these). This would have added a JIT to CPython (the reference implementation) directly, meaning all new Python versions - and all included modules, etc. - get access to JIT compilation. In the PEP 836 authors' own words: Alternative Python implementations, such as PyPy and GraalPy, demonstrate that larger speedups are possible for some Python programs, and we deeply value those projects. However, many users cannot adopt an alternative runtime even when it may perform better on their code due to factors such as supported Python versions, extension compatibility, embedding requirements, deployment constraints, and tooling support. Alternative Python implementations, such as PyPy and GraalPy, demonstrate that larger speedups are possible for some Python programs, and we deeply value those projects. However, many users cannot adopt an alternative runtime even when it may perform better on their code due to factors such as supported Python versions, extension compatibility, embedding requirements, deployment constraints, and tooling support. Experimentation in main? Posted Oct 27, 2026 12:26 UTC (Tue) by marcH (subscriber, #57642) [Link] (1 responses) Apologies if I missed it: why was this happening in the main branch? Too many conflicts with other changes also happening in main? (Not enough to justify IMHO but that could explain) > [a compatibility review] that would involve running the test suites of the top PyPI packages to see if the JIT broke them. The council wanted that timeline moved up significantly. "We think that [Aug. 2028] is way, way too late, and the compatibility review should be an ongoing and continuous process starting as soon as possible". Maybe I'm missing something again but that seems normal and expected for the main branch - even when not enabled by default. I didn't experience it much personally but regressions (in main releases) sound like a relatively frequent complaint about Python... Experimentation in main? Posted Oct 27, 2026 12:46 UTC (Tue) by mathstuf (subscriber, #69389) [Link] I think it is possible, but the use needs to have a signal that the user knows they're "playing with fire". The way we do this for CMake is that there is a variable which needs to be set to a specified value (a randomly generated UUID) for the experiment to become "active" (and its first usage will trigger a warning about it becoming active). If the value is not correct, the feature is ignored. We then change the expected value whenever we update the behavior. With that, projects can't use the "but the value worked last time!" excuse. Basically, we use it as a way to escape Hyrum's Law and committing to any in-progress behavior in the future.