3 ms·
Because the GIL is only a problem in specific sets of problems that the majority of python users won't run into. With the addition of asyncio etc, the negative
by dashwav 7y ago
Because the GIL is only a problem in specific sets of problems that the majority of python users won't run into. With the addition of asyncio etc, the negative of GIL is usually pretty restricted to CPU-heavy, blocking services which the core team decided was a very small subset of users. So removing the GIL would require an extremely heavy rewrite of the way python works at a fundamental basis, and it would break a lot of the "promises" that python affords in regards to memory management and safety.
As an aside, there is currently a PEP that will allow for better concurrency __without__ removing the GIL,
[PEP554](https://www.python.org/dev/peps/pep-0554/ https://www.python.org/dev/peps/pep-0554/)
and a larger project overall for multi-core support, which is (hopefully) being included in 3.9
[Multi-core](https://github.com/ericsnowcurrently/multi-core-python https://github.com/ericsnowcurrently/multi-core-python)