My understanding is that it doesn't make practical sense to remove the GIL; doing so would result in a slowdown of the interpreter[1]: Back in the days of Py

My understanding is that it doesn't make practical sense to remove the GIL; doing so would result in a slowdown of the interpreter[1]: Back in the days of Python 1.5, Greg Stein actually implemented a comprehensive patch set (the “free threading” patches) that removed the GIL and replaced it with fine-grained locking. Unfortunately, even on Windows (where locks are very efficient) this ran ordinary Python code about twice as slow as the interpreter using the GIL. On Linux the performance loss was even worse because pthread locks aren’t as efficient. Since then, the idea of getting rid of the GIL has occasionally come up but nobody has found a way to deal with the expected slowdown, and users who don’t use threads would not be happy if their code ran at half the speed. Greg’s free threading patch set has not been kept up-to-date for later Python versions. > no parallelism for you! This is a bit of a hyperbole; Python supports both hardware threads and processes, both of which can be used to achieve parallelism. Despite the GIL limiting Python code to 1 CPU, many I/O routines will release the GIL while they perform I/O meaning I/O can be done in parallel, and native code can release the GIL to do long computations. Processes can be used to overcome the GIL directly in Python, and the standard library offers support to make this as easy as it is to launch a thread, as well as some higher-level support for parallel-mapping a function across a pool of processes. [1]: https://docs.python.org/3/faq/library.html#can-t-we-get-rid-of-the-global-interpreter-lock https://docs.python.org/3/faq/library.html#can-t-we-get-rid-...