alt Hacker News> For that reason, the Steering Council is formally requesting a Standards Track PEP be authored that the community can discuss and the Steering Council can formally accept (or reject), making the case for the JIT as a supported, non-experimental part of CPython: its guarantees, its maintenance commitments, and its impact on redistributors.
I didn't notice the current PEP was a provisional one. Hope the new one gets approved. The experimental JIT was reported to finally breaking even and surpassing the default interpreter just a couple of months ago[1].
[1] https://fidget-spinner.github.io/posts/jit-on-track.html
Replies
Sure but best case 15% faster clearly isn't worth the complexity of a JIT. It really needs to be at least twice as fast. Pypy pretty much achieves that on average.
Kind of a shit move to suddenly pull the rug once they've finally gotten it working. Should have been kept out of main from the start.
>The experimental JIT was reported to finally breaking even and surpassing the default interpreter just a couple of months ago[1].
Thank You. As someone who don't follow python closely I thought their JIT would be similar to what Ruby has.
Not that Ruby YJIT or ZJIT is anywhere close to what JVM provides, but in this case it seems to be quite far ahead of Python.
Which is surprising given how many major companies are using Python. May be because those using Python are not using it as critical part of work unlike Shopify and Stripe which is their core language?