The main problem is the perception that code would linearly scale if the GIL was removed. Eg on a 4 core machine code would run 4 times as fast. And that the

The main problem is the perception that code would linearly scale if the GIL was removed. Eg on a 4 core machine code would run 4 times as fast. And that the GIL has no value. Both statements are completely false. (A bigger issue is the reference counting anyway. Changing that should be a precursor to GIL removal.) I'm an author of a C extension (apsw) and the GIL is fantastic. Without it the code would be considerably more complicated, longer and likely to have race conditions and similar gnarly bugs. As a Python developer I use: * Multiple processes usually by executing a new process which allows me to easily substitute testing processes and using stdin/stdout * Use networking for talking between parts (allows spreading over multiple machines, failover, redundancy, load balancing etc) * multiprocessing for pure Python work * Threads for I/O bound work or work that waits on other things * C extensions that release the GIL Actually getting rid of the GIL wouldn't help.