== In praise of Python's Global Interpreter Lock It's common to say bad things about the [[GIL WhatTheGILProtects]] (a round of GIL bashing happened recently, for example). I have a contrarian view: I think that the GIL is the right thing for Python. Python needs some concurrency support, if only so that it can make inherently blocking operations into non-blocking ones. At the same time, the thread and shared memory based concurrent programming model is a terrible one that programmers should avoid as much as possible. The GIL is good enough and simple enough to easily do the former (in fact it's [[the only thing you should use the GIL for UsefulPythonThreads]]), while being crappy enough to discourage programmers from writing actual thread and shared memory based concurrent programs, partly because their programs don't get much benefit. Worse thread support would make the blocking to non-blocking transformation too painful. Better thread support would tempt Python programmers into more actual thread-based concurrent programming, with the attendant heartburn. The GIL sits in a sweet spot in the middle: just good enough to be useful yet pointless enough to not be used. (In the process the GIL optimizes for the single-threaded case, which is likely to be the most common one for quite some time even in the [[theoretical ../tech/EconomicsOfCPUPerformance]] glorious multi-core future.) The GIL also means that the core Python developers are not forced to spend a lot of effort supporting a model of concurrency that will ultimately be a dead end. (If shared memory threading is not a dead end for most concurrency work, we are in a lot of trouble.)