Very nice. I've loved PyPy as a way to run Python faster, but it only got to Python 3.12 this September, and that's still beta (https://pypy.org/posts/2026/10/pypy-v801-release.html). That's about 3 years after CPython's 3.12. JIT in CPython itself seems on-again, off-again, so great news that an external approach might be able to take up some slack.
As per the comments from Ken Jin (CPython JIT developer) on the article (at the bottom of the page), the way yk is integrated with CPython isn't really that "external" though: they make use of the existing CPython JIT's tracer, micro optimizations, etc., basically only replacing the copy-and-patch backend. So yk will have to maintain the whole CPython JIT patch (sans copy-and-patch) if they want to retain the same performance after the removal of the JIT compiler from CPython[1].
Good link! Both article and comments hit on reasons JIT projects are so hard and fragile with CPython (e.g. wide scope/touches everything, hasn't gotten over the hump of being obviously better unlike JS's V8, the way CPython hands out raw pointers to C extensions, etc). Helps explain a bit why JS, Lua, Ruby have had more lasting success with JIT acceleration.
In this can-we-please-finally-get-past-the-GIL era, koflerdavid also makes a good point:
> CPython is currently stabilizing its new free-threading mode. The current budget for changes to the whole module ecosystem is therefore already strained. It's simply bad timing for other breaking changes to land since it blow up the test matrix too much.
Very nice. I've loved PyPy as a way to run Python faster, but it only got to Python 3.12 this September, and that's still beta (https://pypy.org/posts/2026/10/pypy-v801-release.html). That's about 3 years after CPython's 3.12. JIT in CPython itself seems on-again, off-again, so great news that an external approach might be able to take up some slack.
I believe the JIT project in CPython has been scrapped, at least officially.
Relevant: https://news.ycombinator.com/item?id=50257419 (Python's experimental JIT to be removed) from 16 days ago
As per the comments from Ken Jin (CPython JIT developer) on the article (at the bottom of the page), the way yk is integrated with CPython isn't really that "external" though: they make use of the existing CPython JIT's tracer, micro optimizations, etc., basically only replacing the copy-and-patch backend. So yk will have to maintain the whole CPython JIT patch (sans copy-and-patch) if they want to retain the same performance after the removal of the JIT compiler from CPython[1].
[1] https://lwn.net/Articles/1102102/
Good link! Both article and comments hit on reasons JIT projects are so hard and fragile with CPython (e.g. wide scope/touches everything, hasn't gotten over the hump of being obviously better unlike JS's V8, the way CPython hands out raw pointers to C extensions, etc). Helps explain a bit why JS, Lua, Ruby have had more lasting success with JIT acceleration.
In this can-we-please-finally-get-past-the-GIL era, koflerdavid also makes a good point:
> CPython is currently stabilizing its new free-threading mode. The current budget for changes to the whole module ecosystem is therefore already strained. It's simply bad timing for other breaking changes to land since it blow up the test matrix too much.
Or the dynamic languages in the genesis of JIT research, Lisp, Smalltalk, Self.