CPython experimental JIT compiler withdrawn after PEP 836 rejected

Brief written by the FOSSWire AI editor from LWN.net How we write

October 26, 2026 1 min read

Key Takeaway

Python's experimental JIT, introduced in CPython 3.13 (2024), is being removed from mainline development after its maintainers withdrew PEP 836 following steering council demands for clearer maintenance, compatibility, and completion plans.

Summary

The experimental just-in-time compiler that landed in CPython 3.13 in 2024 will not advance to supported status. The Python steering council paused JIT work in June 2026, requiring a formal PEP with maintenance commitments, compatibility guarantees, success metrics, and a completion timeline before mainline development could resume.

JIT maintainers responded with PEP 836, titled "JIT Go Brrr: The Path to a Supported JIT Compiler for CPython." After months of community discussion, the PEP's authors withdrew the proposal. No replacement PEP is currently in progress, and the JIT code appears headed for removal from CPython's main branch rather than further refinement.

What ends with the JIT withdrawal

CPython 3.13 JIT origins: The experimental JIT was introduced in the 3.13 release cycle (2024) as a copy-and-patch compiler using LLVM's ORC JIT infrastructure, targeting x86_64 and ARM64 with tiered execution alongside CPython's existing specializing adaptive interpreter.
Steering council block: The council's June 2026 pause demanded an accepted PEP addressing long-term maintenance burden, C API and ABI compatibility constraints, measurable performance targets, and a defined timeline for production readiness.
PEP 836 failure: Despite months of discussion, PEP 836 did not achieve acceptance; its withdrawal by the JIT maintainers signals that the proposed path to supported status could not satisfy core developer concerns or resource constraints.
Current status: Development on the JIT has effectively halted with no successor PEP announced, making removal from CPython main the likely next step rather than continued experimental iteration.

Why it matters

Python distributors and performance-sensitive deployments will continue relying on CPython's interpreter and existing optimizations rather than a native JIT. Projects like PyPy and Cinder retain their relevance as alternative high-performance Python runtimes, while C extension compatibility and deployment predictability remain prioritized over speculative execution speedups in CPython itself.

Original reference: lwn.net →