Assuming the analysis by the Fast CPython team is accurate (https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-3-12-updates/26503/9), getting rid of the GIL is projected to cost 15% of performance on single-threaded code if it were put into Python 3.12. They also extrapolate out and say it could potentially cost 30% for Python 3.14 if the Fast CPython team meet their goals. (FYI the no-GIL PEP projects a 6% cost.)

What is the single-threaded performance cost you're willing to pay to get rid of the GIL?

@brettcannon nobody writes threads anymore, so unless asyncio takes advantage of multiple threads transparently and is no longer cpu bound (but would break many of the assumptions of asyncio), the GIL removal would be an enormous breaking change for questionable gains (or maybe people would write threads again). I shudder to think of all the race conditions libraries like mine are going to be hit with when concurrency guarantees suddenly change

@mike @brettcannon not familiar with "nested event loops" , are you familiar with my approach to this using greenlet for SQLAlchemy? We've solved the problem entirely, just would be nice if stdlib had equivalent functions as the ones we wrote with greenlet.