CPython supported-JIT PEP 836 withdrawn over bandwidth

PEP 836, the proposal for a path to a supported just-in-time compiler in CPython, has been withdrawn. The authors say they lack the personal bandwidth to carry the current draft after Steering Council feedback set a high bar for leaving experimental JIT work in the main repository.

Savannah Ostrowski, posting for the co-authors (Brandt and Ken Jin among them), wrote that the group still backs the technical direction in the PEP, including free-threaded support and a method-based frontend, and remains optimistic about a JIT’s potential in CPython. They plan to publish a reference implementation and link it from the withdrawn PEP so others can explore and extend it.

The council had asked for the PEP to answer maintenance and support plans, how much a JIT would break packages and tools that touch internals (profilers and debuggers included), how to measure impact, where a built-in JIT sits relative to other accelerators and eval hooks, and whether the work was still an open experiment or a concrete design. Feedback posted for the council stressed that in-tree experimentation without a unified design leaves core developers, package maintainers, and users uncertain as behavior and API surfaces shift. What was under review was not a finished production JIT, but whether to keep a defined experiment in main at all.

Brett Cannon said withdrawal means the JIT leaves CPython’s repository; any continuation is up to the community outside that tree. A narrow window under the council’s earlier timeline still existed for a different PEP, though on PEP timescales it was tight.

Separately, Mark Shannon had argued against baking a switch to a method-based frontend into the PEP, calling region selection an internal detail and warning that a forced frontend change could stall progress without clear gains, citing Ruby’s slower YJIT-to-ZJIT transition as a caution. With the PEP gone, that design fight moves out of main along with the code.