Well, all credit to Sam the author, but he "bought" that no degraded performance by adding performance optimizations! Unfortunately, Python 3.11+faster-cpython work has already superseded some of it, i.e negating the trade-in he's trying to accomplish! However, I still hope everyone helps out and that the nogil work can land as default in CPython.
> Unfortunately, Python 3.11+faster-cpython work has already superseded some of it,
Why is that unfortunate? If his patch being slower than python 3.11 isn't acceptably fast despite being faster than every other python version before that then python was never acceptably fast to begin with.
Linux got rid of the BKL ages ago, that the Python community still holds onto the GIL as if it was some multi threading holy grail isn't even remotely funny anymore.
It's unfortunate because I think it makes it slightly less likely that his work is accepted, now that part of the sweet single thread performance gains are already supplied from another source.
>Unfortunately, Python 3.11+faster-cpython work has already superseded some of it, i.e negating the trade-in he's trying to accomplish!
If "Python 3.11+faster-cpython" didn't also remove the GIL, then it didn't negate anything he's trying to acomplish. He wasn't going for a faster Cpython alone, but for a Cpython without GIL.
The first Gil-removal patch I'm aware of was against python 1.4, so it's not like people haven't been trying. The problem has never been removing the GIL per se, but removing the GIL without slowing down the language when running single thread
You could compile Python using the --without-threads configure option, before Python 3.7 [1] or thereabouts.
[1] 3.7.0 is the first major release following the removal of the config option in https://github.com/python/cpython/issues/75551 .. there's also a 2021 comment about "This has unfortunately turned out to be a blocker on getting WASI support as there's not direct threading support in WebAssembly."
Also: there were lots of independent projects to remove the GIL/speed up Python: from Google, Dropbox, and others.
But due to the leadership/community model/aversion to big changes (except for alienating people with 2 to 3 changes) none of this was in the context of CPython, they were independent versions, that never caught on, and didn't leave anything (or much) behind to the regular CPython when they folded.
This is the first suggestion that doesn’t degrade single threaded performance.