I agree that the "faster CPython" project is way oversold. I have compared real world code with numerical and string operations without any network or disk accesses. 3.12-beta only uses 20-25% less time than 3.8.

That's the level of 2.7.

I seems that the old boys are desperate for some bullet point features for the next release to impress their corporate masters. So they use the work of Sam Gross, but they will slowly get the credit over time.

There's a big history of projects underfunded, overpromising, and getting tossed aside, not even halfway there, when it comes to a faster Python.

In a PL-fantasy-league they would just heavily sponsor Lars Bak to create a team and work on a new Python interpreter!

Yeah, but this project is actually delivering stuff that's been shipped. That's perhaps why it's taking a bit longer. As far as I can tell, they haven't gotten to the boxing removal stuff yet where the really big wins probably are.

As for your fantasy, we already have PyPy.

>Yeah, but this project is actually delivering stuff that's been shipped.

The initial selling point was ~ 5x speedup over 5 years.

This is over a year now, with far more people and resources plus the backling of a major industry-player (MS), and it's been like 20%-30% improvements at best, and even those in danger to be wiped out by the no-gil change.

>As for your fantasy, we already have PyPy.

That's nowhere near Lars Bak level fantasy results...

It was actually 5x in 4 years (1.5x per year).

As you said we see 20-30% at best. And several important workloads have important slowdowns (for example coveragepy runs 30-50% slower).

The GIL is an academic problem which has little real world relevance.