# PEP 836: JIT Go Brrr: The Path to a Supported JIT Compiler for CPython **URL:** \ **Category:** PEPs\ **Created:** [July 3, 2026, 4:45pm UTC](https://discuss.python.org/t/pep-836-jit-go-brrr-the-path-to-a-supported-jit-compiler-for-cpython/108010 "2026-07-03T16:45:34Z")\ **Posts on this page:** 1\ **Showing post:** 75
**Author:** ![pablogsal](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pablogsal/32/32246_2.png) [@pablogsal](https://discuss.python.org/u/pablogsal)\ **Post date:** [October 29, 2026, 4:49pm UTC](https://discuss.python.org/t/pep-836-jit-go-brrr-the-path-to-a-supported-jit-compiler-for-cpython/108010/75 "2026-10-29T16:49:45Z")
I understand that the JIT is something people in this community have been waiting for, the people building it have poured years into it, and watching the PEP get withdrawn after a pause that the SC asked for is frustrating. I understand that frustration and I don’t want to dismiss it. But understanding how people feel is not a justification for spreading rumours and misinformation about how this happened **The SC has not killed the JIT. The SC has not rejected PEP 836. The SC has not made any decision on PEP 836 at all, because the PEP was never submitted to us for one.** What we did was unusual in the other direction: **we posted our feedback publicly before submission because we have been asked for it by the authors after a office hours meeting**. This was done also to shorten the loop and to be transparent about where we stood. That feedback said the PEP answered the questions we had asked, that there were no significant missing pieces, that the remaining items were things to consider rather than blocking criteria, and that we were not setting the bar for supported status at all, only deciding whether the experiment continues in `main`. The authors then withdrew, by their own account because they didn’t have the bandwidth to carry it forward. That is their call, I respect it, and I am grateful for the work they put into the PEP. But calling it an SC decision is simply false. Also the requirements were not impossible. **They were five questions: who maintains this, how does it interact with the features and tools CPython already supports, what are the measurable goals, how does it relate to other JITs, and is the architecture stable**. Any Standards Track PEP that touches the runtime answers those. Free-threading answered them. PEP 703 took five months of SC deliberation, was accepted with explicit conditions including the right to roll all of it back, and then needed a second PEP with a further list of Phase II requirements before the experimental label came off. That was the process working as intended, and nobody called it an abuse. The JIT was being asked for the first of those steps, three releases after landing in `main` on an Informational PEP. We hold the same bar for everything, and we were not going to hold a lower one here because the code was already merged. Holding that bar it’s literally the damn job. And the reason we asked for a PEP is not a mystery. This came after several years of the JIT living in `main` with the design changing underneath everyone and nothing agreed with the community: uops and the bytecode DSL in 3.12, trace projection and copy-and-patch in 3.13, more interpreter refactoring in 3.14, a rewrite to trace recording in 3.15, and now a proposed move to a method frontend. Every one of those reached into the interpreter that every core developer, tool author and distributor depends on, none of it went through a PEP, and by PEP 836’s own account the first two produced no speedup. That is not a criticism of the people doing the work; experiments iterate, and we said in June that the recent results were real. It is exactly why, after several years, a change of this reach needs an agreed design and agreed commitments from the whole community, and that is what a PEP is. The SC’s responsibility is to the whole project, including the people who maintain the interpreter, the tools and the distributions that a JIT touches, and we would be failing them if we waved this through because it was already in the tree. As for the idea that the SC harbours some hidden hostility to the project: three of the five of us have contributed to the JIT in different ways, including helping to solve some complicated challenges that require days and days of iteration. We want one the whole project can stand behind. **ALL of the PEP authors can corroborate this if anyone needs it** I take the point that people want more communication from us, and that is fair. If the people who were at the sprints want to write up what was discussed, I would welcome it, and the SC will keep this thread informed as things develop. But frustration, however legitimate, does not make a rumour true, and the claim that the SC engineered this outcome is just nonsensical. @savannahostrowski herself is in the Steering Council and has heard all our deliberations and she can corroborate that there is no hidden conspiracy to kill the JIT compiler. The JIT has not been cancelled. The project has been asked to do what every other change of this magnitude to the runtime has to do and has done before: convince the project. And spreading misinformation and uninformed rumors is simply not helpful --- _[View the full topic](https://discuss.python.org/t/pep-836-jit-go-brrr-the-path-to-a-supported-jit-compiler-for-cpython/108010)._