--- title: Python's experimental JIT to be removed | daily.dev description: CPython's experimental JIT compiler is being withdrawn after its authors pulled the PEP meant to make it a supported feature. The JIT, added by Brandt Bucher... canonical: https://daily.dev/posts/python-s-experimental-jit-to-be-removed-2qgwrdoly twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Python's experimental JIT to be removed | daily.dev og:description: CPython's experimental JIT compiler is being withdrawn after its authors pulled the PEP meant to make it a supported feature. The JIT, added by Brandt Bucher... og:url: https://daily.dev/posts/python-s-experimental-jit-to-be-removed-2qgwrdoly og:image: https://api.daily.dev/og/posts/2QGWRDOLy.png og:image:alt: Python's experimental JIT to be removed og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Python's experimental JIT to be removed **[Hacker News](https://daily.dev/sources/hn)** · 11 min read · 2 upvotes · 0 comments ## Summary CPython's experimental JIT compiler is being withdrawn after its authors pulled the PEP meant to make it a supported feature. The JIT, added by Brandt Bucher to CPython for Python 3.13 in 2024, had been proceeding on the basis of informational PEP 744. In June the steering council paused JIT work in the main branch until a standards-track PEP addressed maintenance, compatibility and security concerns. Authors Brandt Bucher, Savannah Ostrowski and Ken Jin drafted PEP 836 in response, but on October 19 Ostrowski announced the PEP was withdrawn, citing lack of bandwidth. The JIT is likely to be removed from CPython's main branch early in the Python 3.16 development cycle. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Is the experimental JIT compiler being removed from CPython? Yes, the JIT is expected to be removed from CPython's main branch, likely early in the Python 3.16 development cycle. This follows the October 19 withdrawal of PEP 836, the standards-track proposal meant to make the JIT a supported, non-experimental feature. The JIT was added to CPython in 2024 for Python 3.13 by Brandt Bucher but never reached a formal accepted PEP. _Track how CPython's JIT removal might affect performance-sensitive code by following the discussion on daily.dev._ ### Why did the Python steering council reject PEP 836 for the JIT compiler? The council did not outright reject it but asked for more detail, saying PEP 836 'mostly answers the questions' but was too vague or optimistic on areas like user-visible behavior changes, security review, and the compatibility review timeline (originally set for a Python 3.17 release candidate around August 2028, which the council called 'way, way too late'). Authors withdrew the PEP rather than continue revising it. _Developers weighing CPython's JIT maturity for production use can follow this governance debate on daily.dev._ ### Who created the CPython JIT compiler and when was it added? Brandt Bucher added the experimental JIT to CPython in early 2024, and it shipped as part of the Python 3.13 release. He later collaborated with Savannah Ostrowski and Ken Jin on PEP 836, an attempt to formalize the JIT as a supported CPython feature, which was withdrawn on October 19 due to insufficient bandwidth to address the steering council's feedback. _Anyone deciding whether to rely on CPython's JIT can follow its status changes on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 145 comments across hackernews, lobsters (as of 2026-10-28). **TL;DR:** Reaction is split between viewing the steering council's process as prudent governance that correctly flagged real maintenance/security/scope risks, and seeing it as bureaucratic overreach that burned out volunteer developers and killed a promising performance effort; many also pivot to discussing alternative paths to Python speed (PyPy, GraalPy, Numba, Cython, Rust rewrites). **Sentiment:** 15% positive · 45% mixed · 40% skeptical **The case for** - Some see the steering council's demand for clear scope, success criteria, and a support plan as reasonable stewardship of critical infrastructure. - A few note the process was relatively open and reached a decision faster than expected, calling it good governance rather than true bureaucracy. - Alternatives like Numba, Cython, PyPy, and GraalPy are highlighted as viable existing paths to better Python performance. **The pushback** - Many argue the JIT's removal reflects bureaucratic/process overreach that is at odds with how experimental, iterative JIT development actually works. - Several blame lack of sustained funding/staffing (e.g., Microsoft pulling support) rather than the developers for the project's failure. - Some worry this signals Python will remain stuck with mediocre performance while wasting compute/electricity at scale. - A few raise security concerns about JIT-introduced attack surface (RWX memory, type confusion bugs seen in other JIT engines), though others push back that Python's threat model differs from JS. **By community** - hackernews (mixed): Long, wide-ranging thread debating whether the steering council's process was reasonable stewardship or bureaucratic overreach, with many tangents into JIT security, alternative runtimes, and AI-assisted rewrites. - lobsters (mixed): Smaller thread split between praising the steering council's pragmatic stewardship and calling it death by bureaucracy that burned out the developers. **Hottest debate:** Whether requiring a formal standards-track PEP with clear scope and success metrics for a JIT is sensible governance or bureaucratic overreach incompatible with how experimental compiler work actually proceeds. **Open questions** - What is the current status of the broader Faster CPython effort now that Microsoft has withdrawn funding and staff have moved elsewhere? - Will any alternative Python runtime (PyPy, GraalPy, CinderX) gain enough ecosystem adoption to fill the performance gap? - Is Python's free-threading (no-GIL) effort still on track despite the JIT's removal? **Highlights** > Gonna dump a technical hot take here. Python is a mature production language with a lot of users. Even before it was huge - like 20 years ago when I was in college - getting a small backwards compatible API change into a python extension module (gnu readline in my case) required convincing GvR personally that the API change was necessary. Every JIT attempt I've seen for python just tries to cut too deep in the first pass, and scope themselves too large. I believe any successful attempt at optimizing python performance from JIT will FIRST start with a 100% semantically compatible hidden type model for optimizing object property access and method dispatch. The single biggest performance delta in most dynamic language jits come from that, not from optimizing guards off of bytecode operations or from compiling to machine code. It's from converting hashtable lookups into constant-time guard + offset lookups. The hidden type model is also a hard nut to crack. It needs to perserve dict semantics which have very dynamic behaviour via the various `__*__` methods, and handle exotics scope objects since scoped name lookups are the most common ones which have their own exotic behaviours (I remember python providing some ability for callee frames to inspect caller scopes in some limited ways). > — [kannanvijayan on hackernews · 2 comments](https://news.ycombinator.com/item?id=50258052) > From https://discuss.python.org/t/pep-836-jit-go-brrr-the-path-to... : > We want the PEP to be clear that it’s ultimately the JIT team’s responsibility to find solutions for these packages and tools, and how to deal with situations where a tool can’t be supported or made to work Is it just me or is this absurdly impossible, to the point of willfully killing the project? Committing a team of brilliant compiler engineers to doing free consulting ad infinitum for every bit of tooling in the world, however hacked-together? The alternative would be to have the bravery to say: this is the way forward to keep this language relevant into the future, and as a steering committee we collectively own that some tooling may be out of date. Instead, this is a signal that Python is going to rest on its laurels for a very long time. > — [btown on hackernews · 2 comments](https://news.ycombinator.com/item?id=50258282) > Looks like a death by bureaucracy to me. Basically the JIT was gathering a lot of steam/community attention, then the steering committee started demanding a bunch of paperwork to approve it. Reading the motivation for the withdrawal pretty much confirms that the steering committee burned out the developers working on it. Very disappointing to see this happen. Don't really get the praise for the process, this entire thing just reeks of the steering committee getting upset that something is being worked on without their explicit approval stamp, it getting a lot of positive attention in the press (the JIT was talked about by tech news in much the same breath as fixing up the GIL), and subsequently choosing to ruin it for everyone. The PEP process has mostly been good at iteratively improving the language, but it's always struggled at fixing up some of the worse fundamentals of Python. There's a reason why python3k/python 3 had to basically get crowbarred through by BDFL edict. Sometimes the sheer volume of paperwork processes like this demand doesn't square well with the actual work involved. > — [noirscape on lobsters · 4 points](https://lobste.rs/s/cajuq6/python_s_experimental_jit_be_removed#c_dmjzrd) > I think this is a major issue with requiring a PEP for what's a performance optimization. JITs are big nasty things that by their nature have to do a lot of things. You are basically saying "Give us a PEP for a new python interpreter and compiler". What they do is fuzzy by their nature because optimizations are very rarely universally beneficial. It's a game of measuring, looking for regressions, and tackling the biggest problem next for whatever sample applications you have available. You always run into the risk of overfitting on top of all that (You may have made django faster, but you've made flask slower). This is the sort of thing that, IMO, should not go through the PEP process. It's an implementation detail for the runtime. Imagine, for example, if the JVM needed a bunch of JEPs for JIT improvements. They'd never get done. Or if any javascript engine needed ECMA acceptance before they could do a new JIT optimization. > — [cogman10 on hackernews · 2 comments](https://news.ycombinator.com/item?id=50259625) > A sad day for CPython but it doesn't have to be a sad day for Python. There is a fully maintained implementation of Python 3.13 that has an advanced JIT compiler. Once your Python warms up it can be 4x faster or higher (depending on what your program is doing). That implementation is called GraalPy and it builds on the JVM: https://graalpy.org/ A bit like Chrome there's a fully open source version and a proprietary version with a few extra bells and whistles, but the latter is entirely free for both open and commercial usage (you can't redistribute it for a fee). So you may as well use it. It has other interesting features • Scalable pauseless GC • Single binary distribution of Python programs (like Go) • Fancy and optimized interop with other languages including Java, JavaScript, Kotlin, Ruby and any other Truffle language. • Supports native extensions. Tested and works with common libs like SciPy, NumPy, PyTorch, Pandas etc: https://graalpy.org/python-developers/compatibility/ • They're working on a GIL-free mode In recent weeks there has been a release of a new web framework for Python that only runs on GraalPy, called Pyronaut (https://pyronaut.io/). It takes advantage of JVM interop to expose the Micronaut framework, which is similar to Spring for those who know it. Thanks to the JIT and well optimized base libraries it runs extremely fast, being about 3x faster than FastAPI+Granian, or 7x faster than Flask+Gunicorn and having many more features. https://www.youtube.com/watch?v=zo6L7bxn4OY (that was presented at Devoxx but the Pyronaut devs will start touring Python specific conferences soon) So although CPython may not have made it past the JIT milestone, that doesn't mean Python as a language or community has to fail it. It does require openness to alternative implementations, but historically Pythonistas have been fairly good about that (e.g. Pypy was embraced back when it was more active). This stuff does require you to accept that it's made by Oracle, but as it's open source, that should be OK. Disclosure: I sit next to some of the people who work on this stuff. > — [mike\_hearn on hackernews · 2 comments](https://news.ycombinator.com/item?id=50258601) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50257419) · 236 points · 139 comments - [lobsters](https://lobste.rs/s/cajuq6/python_s_experimental_jit_be_removed) · 56 points · 6 comments ## Similar posts on daily.dev - [An announcement from the Steering Council regarding the JIT project](https://daily.dev/posts/an-announcement-from-the-steering-council-regarding-the-jit-project-weovmzlzi) · Lobsters · 2 upvotes · 0 comments - [Python JIT compiler project under threat after steering council says proper process wasn't followed](https://daily.dev/posts/python-jit-compiler-project-under-threat-after-steering-council-says-proper-process-wasn-t-followed-poxpmbb92) · DEVCLASS · 6 upvotes · 0 comments - [Python's JIT Faces Some Challenges and Other News for July 2026 – Real Python](https://daily.dev/posts/python-s-jit-faces-some-challenges-and-other-news-for-july-2026-real-python-quau8y20z) · Real Python · 3 upvotes · 0 comments - [Python 3.15’s JIT is now back on track](https://daily.dev/posts/python-3-15-s-jit-is-now-back-on-track-mhtoosety) · Hacker News · 2 upvotes · 0 comments - [Python 3.14 and its New JIT Compiler](https://daily.dev/posts/python-3-14-and-its-new-jit-compiler-sx1mbtt4z) · Towards Data Science · 1 upvotes · 0 comments --- Tags: [#python](https://daily.dev/tags/python), [#open-source](https://daily.dev/tags/open-source), [#compiler-optimization](https://daily.dev/tags/compiler-optimization), [#cpython](https://daily.dev/tags/cpython) [View this post on daily.dev](https://daily.dev/posts/python-s-experimental-jit-to-be-removed-2qgwrdoly) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Python's experimental JIT to be removed","url":"https://daily.dev/posts/python-s-experimental-jit-to-be-removed-2qgwrdoly","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/python-s-experimental-jit-to-be-removed-2qgwrdoly"},"datePublished":"2026-10-27T13:55:28.514Z","dateModified":"2026-10-28T15:25:48.421Z","description":"CPython's experimental JIT compiler is being withdrawn after its authors pulled the PEP meant to make it a supported feature. The JIT, added by Brandt Bucher...","image":"https://media.daily.dev/image/upload/s--CxzD6vbw--/f_auto/v1722860399/public/Placeholder%2005","thumbnailUrl":"https://media.daily.dev/image/upload/s--CxzD6vbw--/f_auto/v1722860399/public/Placeholder%2005","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/python-s-experimental-jit-to-be-removed-2qgwrdoly","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"python,open-source,compiler-optimization,cpython","timeRequired":"PT11M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Python's experimental JIT to be removed"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/python-s-experimental-jit-to-be-removed-2qgwrdoly#faq","mainEntity":[{"@type":"Question","name":"Is the experimental JIT compiler being removed from CPython?","acceptedAnswer":{"@type":"Answer","text":"Yes, the JIT is expected to be removed from CPython's main branch, likely early in the Python 3.16 development cycle. This follows the October 19 withdrawal of PEP 836, the standards-track proposal meant to make the JIT a supported, non-experimental feature. The JIT was added to CPython in 2024 for Python 3.13 by Brandt Bucher but never reached a formal accepted PEP. Track how CPython's JIT removal might affect performance-sensitive code by following the discussion on daily.dev."}},{"@type":"Question","name":"Why did the Python steering council reject PEP 836 for the JIT compiler?","acceptedAnswer":{"@type":"Answer","text":"The council did not outright reject it but asked for more detail, saying PEP 836 'mostly answers the questions' but was too vague or optimistic on areas like user-visible behavior changes, security review, and the compatibility review timeline (originally set for a Python 3.17 release candidate around August 2028, which the council called 'way, way too late'). Authors withdrew the PEP rather than continue revising it. Developers weighing CPython's JIT maturity for production use can follow this governance debate on daily.dev."}},{"@type":"Question","name":"Who created the CPython JIT compiler and when was it added?","acceptedAnswer":{"@type":"Answer","text":"Brandt Bucher added the experimental JIT to CPython in early 2024, and it shipped as part of the Python 3.13 release. He later collaborated with Savannah Ostrowski and Ken Jin on PEP 836, an attempt to formalize the JIT as a supported CPython feature, which was withdrawn on October 19 due to insufficient bandwidth to address the steering council's feedback. Anyone deciding whether to rely on CPython's JIT can follow its status changes on daily.dev."}}]} ```