(Posted for the whole Steering Council.) As we’ve announced before, the Steering Council has decided to accept PEP 703 (Making the Global Interpreter Lock Optional in CPython) . We want to make it clear why, and under what expectations we’re doing so. It is clear to the Steering Council that theoretically, a no-GIL (or free-threaded) Python would be of great benefit, and the majority of the community seems in agreement. Threads have significant downsides and caveats, but they are widely adopte...
It’s because, in Python, you don’t actually get a parallel speed up when working with threads in CPU heavy tasks, even for embarrassingly parallel problems. This is because CPython implements some concurrency safety for primitive objects by using a global lock for all threads that ensures that only one of them has the interpreter at a time (meaning only one thread runs at a time).
From the CPython built-in threading library documentation:
Until 3.13 we won’t have any built-in way of using multiple cores to speed up CPU bound tasks with just python code, short of creating new processes. Sub-interpretters in 3.12 can now have their own GIL, but that won’t have a python interface until 3.13 releases.