I’m staying out of the #Python nogil discussion, b/c I don’t feel like I have a lot to add, but I need to plant my flag now:

Leaving aside the INCREDIBLE effort Sam went thru, the discussion around it is disingenuous with constant goal post moving and frankly myopic.

Yes, threads as a user-level abstraction are BAD.

But we’ve never built higher-level abstractions for them and guess what: asyncio gets 1.5–2.5x faster on nogil w/o any API being designed for it: https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-3-12-updates/26503/17

[1/4]

PEP 703: Making the Global Interpreter Lock Optional (3.12 updates)

We (the Faster CPython team) have taken a careful look at the PEP and I have written up a summary. It is mainly about performance, but also compares PEP 703 to multiple interpreters. I have attempted to be objective, please say if you think I am being unfair. Performance assessment Performance comparison of NoGIL with the status quo PEP 703 claims that NoGIL has a 6% execution overhead on Intel Skylake machines, and 5% on AMD Zen 3. Our benchmarking shows an 11% overhead on our (Cascade Lak...

Discussions on Python.org

@hynek

100% agree with you, and would like to add a couple of observations:

1. Adding async/await to Python is in my book a much bigger change han 2->3, you have to re-write everything since no code can be reused. I cannot believe it went through the SC so easy. (When the crazy walrus discussion made Guido step down)

2. Someone proposed calling it “Multicore Python” instead of nogil, I think that is a great proposal 🙂

It is beyond me why Multicore Python (PEP 703) is not already accepted