Python's experimental just-in-time compiler is being pulled from CPython's main branch — not because the technology failed, but because its champions ran out of bandwidth to satisfy the governance process that should have preceded its inclusion. The JIT was merged into CPython 3.13 in early 2024 by Brandt Bucher, who had presented the work at a core developer sprint but had not submitted the standards-track PEP normally required for a feature of this magnitude. Instead, an informational PEP 744 was drafted after the fact — a document that describes but does not authorize. The steering council let this arrangement ride for over a year before acting. In June 2025, the council formally requested a proper standards-track PEP addressing maintenance commitments, compatibility guarantees, security review, and clear success metrics, with a six-month deadline. The implicit message: prove the JIT belongs in CPython, or it gets ripped out. Bucher, Savannah Ostrowski, and Ken Jin responded with PEP 836, titled with characteristic optimism: 'JIT Go Brrr.' The council's September feedback was thorough and pointed. PEP 836 'mostly' answered the questions, but the council found its compatibility timeline too late (a review at the Python 3.17 release candidate in August 2028 was deemed 'way, way too late'), its security discussion underserved, its optimism about user-visible behavioral differences unwarranted, and its design process too insular. The council wanted a compatibility review as 'an ongoing and continuous process starting as soon as possible,' not a checkbox three years out. On October 19, the PEP authors withdrew. Ostrowski's statement was gracious but clear: 'We don't feel we have the personal bandwidth to carry the current version forward.' The technical conviction remained — the team still believes in the direction, including free-threaded support and a method-based frontend — but the governance lift exceeded what three people could carry alongside their other responsibilities. Ostrowski is simultaneously release manager for Python 3.16 and 3.17 and a steering council member. Brett Cannon confirmed no alternative PEP was likely, since all active JIT contributors were already authors on PEP 836. The removal will happen early in the Python 3.16 development cycle. The reference implementation will be linked from the withdrawn PEP so the community can fork and continue the work independently if interest materializes. Whether anyone picks it up is an open question — JIT compilers are hard, and the intersection of people who understand CPython internals, copy-and-patch compilation, and have the time to shepherd a major PEP through governance is vanishingly small. This episode exposes a structural tension in CPython's development model. The JIT was allowed into main without proper authorization, creating a year-plus fait accompli that the council then had to unwind under political pressure. The council's feedback was substantive — concerns about platform parity, security, memory impact, and interaction with external JITs like CinderX and Numba are real engineering questions. But the asymmetry is notable: the bar for removal was a six-month PEP process that would tax any small team, while the bar for inclusion was apparently just a conference talk and a merge. The deeper question is whether CPython's governance model can accommodate ambitious experimental work at all. The council is right that experiments in main create maintenance burdens and API instability for the entire ecosystem. But if every major technical bet requires a multi-month standards-track PEP before meaningful work can begin in the main codebase, CPython's ability to adopt performance-critical innovations will remain constrained by the bandwidth of the few people willing to do both the engineering and the paperwork.
