The authors of CPython's proposal for a supported just-in-time compiler withdrew it on October 19, 2026, citing limited personal bandwidth. The withdrawal leaves the path to continued experimental JIT development in CPython's main repository uncertain. It does not establish that the code has been removed or that removal will happen automatically on a fixed date.
Savannah Ostrowski announced the withdrawal. PEP 836, co-authored by Ostrowski, Ken Jin and Brandt Bucher, is marked withdrawn. The supplied sources do not identify a release that will ship without the JIT.
The condition and its qualifications
The council's June 5 announcement set a six-month window for a proposal to be submitted and resolved, putting the original window's end around early December 2026. Its stated condition was that, without an accepted proposal, JIT code must leave the main branch and development must continue outside the main Python repository.
The same discussion qualified that timing. Pablo Galindo Salgado said the council would be flexible if a proposal were stuck in discussion or awaiting a council decision, and that the authors or community could request an extension. Thomas Wouters also said missing the six-month deadline would not necessarily mean immediate removal. These comments establish flexibility, not that an extension has been granted.
The June announcement also paused new JIT features, optimizations and performance work on main pending acceptance, while allowing bug and security fixes. It asked for maintenance commitments, compatibility with existing Python features and tools, and measurable goals.
The council's September feedback clarified the immediate decision: whether to continue a defined JIT experiment in main. Declaring the JIT a supported feature would be a later question.
That distinction matters for package and tooling maintainers. The council described uncertainty about changing behavior and APIs, and called for compatibility review to begin as soon as possible and continue throughout development, rather than wait until the final part of the proposed schedule.
What the performance figures establish
The withdrawn proposal describes the existing JIT as experimental and opt-in in Python 3.15. It reports roughly 4-12% geometric mean speed improvements over the interpreter on the pyperformance suite across measured Tier 1 platforms. Those are the proposal authors' benchmark results, not measurements by MrKeyoor or a promise about an application's performance.
PEP 836 proposed further work on compatibility with free-threaded Python and on the build process for distributors. Its larger performance goal concerned a JIT running with free-threading. These were proposed milestones, not delivered capabilities established by the withdrawal.
The council also warned that pyperformance can underrepresent common Python workloads. Together, the documents explain why benchmark gains alone could not settle the decision about continued development: maintenance, compatibility and the impact on real workloads also needed examination.
Ostrowski said the authors would make a reference implementation available and link it from the withdrawn PEP. Developers planning around future JIT improvements should check for that implementation and an explicit council decision, removal change or release note. Evaluate the interpreter used in deployment, and keep the withdrawn proposal's targets out of committed performance plans.