Python JIT Authors Withdraw PEP 836, Leaving Removal From Main as the Default

The people who built CPython's experimental JIT compiler have withdrawn the proposal meant to keep it in the language. PEP 836 was marked withdrawn on October 19, 2026, which leaves the Python Steering Council's June ultimatum standing: no accepted PEP within six months, and the JIT code comes out of the main branch.

LWN reported on October 26 that Savannah Ostrowski, one of the PEP's three authors, announced the withdrawal and cited limited personal bandwidth. The PEP page itself lists the resolution date and gives no reason. Brett Cannon said work would stop in the main repository, and LWN expects the JIT to be removed early in the Python 3.16 development cycle.

What the Steering Council asked for on June 5

The council posted its announcement on June 5, signed by Pablo Galindo Salgado on behalf of the whole body. It asked for a Standards Track PEP making the case for the JIT as a supported, non-experimental part of CPython. Until one was accepted, no new JIT features or optimizations were to land on main. Bug and security fixes were still allowed.

The text set a six-month window. If it lapsed, in the council's words, "the JIT code must be removed from the main branch," and development would continue elsewhere. Galindo later said in the thread that six months was "a first goal to anchor, not a bureaucratic deadline," and that extensions could be requested.

The Register recorded the reaction from inside the project. Mark Shannon, a key JIT contributor, said that "stopping all development until a PEP is accepted puts us in an awkward position," and asked for a grace period of "a month or two."

What PEP 836 promised and what the council said

PEP 836, "JIT Go Brrr: The Path to a Supported JIT Compiler for CPython," was created on July 2 by Ostrowski, Ken Jin and Brandt Bucher. It proposed a roughly 2.5-year path with three gates, shown below.

Milestone	Deadline	Requirement
Year 1	3.16 first beta	Method-based frontend, at least 5% gain with the GIL
Year 2	3.17 first beta	20% geometric mean on pyperformance, JIT plus free-threading
Year 2.5	3.17 first release candidate	Compatibility reviews against popular PyPI packages

On September 21 the council said the PEP answered its questions "although perhaps some less convincingly than others," according to LWN. Ostrowski abstained as a co-author. It asked for a ten-point list to be addressed, called the PEP "overly optimistic" on user impact and described security as "an underserved area."

The sharpest line was about timing. The compatibility review fell at the first 3.17 release candidate, expected around August 2028, which the council called "way, way too late."

How fast the JIT is today

The numbers are modest, and they are the project's own. The Python 3.15 release notes claim an 8 to 9 percent geometric mean improvement over standard CPython on x86-64 Linux, per The Register. PEP 836 puts the current JIT at about 4 to 12 percent on pyperformance across Tier 1 platforms.

1. M3 Pro, macOS (JIT+TAILCALL)12.6 % faster
2. AmpereOne, Linux aarch647.3 % faster
3. i5-8400, Linux x86_646.9 % faster
4. Ryzen 5 3600X, Windows (JIT+TAILCALL)4.7 % faster

Source: PEP 836, peps.python.org, accessed 2026-10-27

The PEP's own prototype of the planned method-based frontend came in at 5 to 6 percent over JIT off on a GIL-enabled build, below the 7 to 8 percent of the current tracing design on the same x86-64 Linux setup. The authors were asking for a slower design now against a 20 percent target.

What happens next

The JIT is still in 3.15, disabled by default and switched on with PYTHON_JIT=1. Python 3.15 is expected this month.

Dunc Graham suggested in the discussion that an alternative PEP might still fit inside the window. Cannon said that was unlikely. The authors told readers they still believe in the technical direction, including free-threaded support, and planned to make the reference implementation available. LWN had no reply from them at publication.

The removal itself is tracked under PEP 826, the 3.16 schedule. The six-month window from June 5 closes in December, so the next thing to watch is the first 3.16 alpha after the code comes out. For another maintainer-run performance claim, see Stalwart 1.0; for open-source tooling under strain, ThinkRail.