Python Language Summit: Python Without the GIL

&gt; “We need to lay out a plan of how to proceed,” remarked Pablo Galindo Salgado. “Just creating a PR with 20,000 lines of code changed is infeasible.”<p>One of the saddest things about popular open-source projects like Python is how inevitably the maintainers become worn down and jaded over time, due to constantly filtering and protecting Python from dumb or nonsensical ideas.<p>Then when something like this comes along, a true game changer, maintainers have no energy or goodwill left to collaborate on these infinitely important initiatives, like removing the dogdamn GIL. This is way more significant than everything I&#x27;m aware of that&#x27;s happened since the birth of the language. All other things have been, trivial miuntiae in comparison.<p>It bears repeating: &quot;everything else has been <i>trivial minutiae</i> in comparison to a GIL-ectamy for Python.&quot;<p>It cannot be understated, removing the GIL will be a HUGE deal for Python! It&#x27;s an ugly wart which has existed for about 30 years, and <i>nobody else has produced and delivered a working solution to the community</i>.<p>I wish Team Python would welcome GIL Eradication with open arms and a supportive attitude. This would look like focusing on helping identify and implement solutions to the impediments rather than simply pointing out problems and then helicoptering away.

I tried the nogil branch out a couple of weeks ago, after running into a GIL issue with some of my code. I used the Docker image they provide.<p>It worked! I was stunned at how easy and effective it was. My page load time dropped from 77ms to 47ms when I ran some of the code in parallel.<p>I wrote some notes on that here: <a href="https:&#x2F;&#x2F;simonwillison.net&#x2F;2022&#x2F;May&#x2F;6&#x2F;weeknotes&#x2F;#nogil" rel="nofollow">https:&#x2F;&#x2F;simonwillison.net&#x2F;2022&#x2F;May&#x2F;6&#x2F;weeknotes&#x2F;#nogil</a>

Folks, the whole point of this effort and what stands it apart from previous GIL-removal efforts is that it&#x27;s carefully designed to:<p>1. Give the performance-benefits of GIL removal for multi-threaded code.<p>2. Not hurt the performance of single-threaded code, hopefully improving it too.<p>3. Not break any pure Python code that relies on the semantics of the GIL.<p>4. Minimize impact to extensions.<p>If you&#x27;re commenting here that this is going to break things w&#x2F;o having read the design doc, you&#x27;re contributing FUD. It&#x27;s disappointing to see the discussion go this way.<p>Here&#x27;s Sam&#x27;s design doc:<p><a href="https:&#x2F;&#x2F;docs.google.com&#x2F;document&#x2F;d&#x2F;18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0&#x2F;edit" rel="nofollow">https:&#x2F;&#x2F;docs.google.com&#x2F;document&#x2F;d&#x2F;18CXhDb1ygxg-YXNBJNzfzZsD...</a><p>Some highlights:<p><i>The project aims for a concurrency model that matches the threads + shared memory model implemented in common operating systems and in programming languages like Java, C++, and Swift. We also aim for similar safety guarantees to Java and Go -- the language doesn’t prevent data races, but data races in user code do not corrupt the VM state. (Notably, Swift and C++ do not have this property: data races in those languages may corrupt VM state leading to segfaults). This strikes a balance between safety and performance. Weaker guarantees, like in Swift and C++, can make debugging difficult, while much stronger guarantees can limit flexibility or hamper performance.<p>Compatibility:<p>The vast majority of Python programs should not require any changes to Python code to continue working. Most of the issues I have encountered so far are due to being based on 3.9.0a3 and libraries using features from the 3.9 final release. A few of the issues have been due to changes to code object internals or the bytecode format, but so far I have been able to address those by making changes to the interpreter to improve backwards compatibility.<p>All extensions that use the Python C API will require re-compilation, even the few that are limited to the stable ABI. (The reference counting changes do not preserve the stable ABI).<p>To compile successfully, some C API extensions will need minor modifications, typically replacement of direct access of PyObject reference count fields with the Py_REFCNT macro.<p>To run successfully, some C API extensions need modifications to protect global data structures in C code that were previously protected by the GIL. For an example, see these two patches to NumPy.</i>

I don&#x27;t mean to troll, but I have to say the GIL is not and never has been a problem with Python. It&#x27;s weird to me that this one tiny issue has grown into such a big waste of time, energy, and attention. I&#x27;ve written Python for something like twenty years now and never once had a problem due to the GIL.<p>It&#x27;s a classic case of &quot;you&#x27;re doing it wrong&quot;: Python supports concurrency in several useful ways, and specifically does NOT support it in one particular very useful way. If you have somehow arranged to bang your head on that one specific thing that Python doesn&#x27;t do, and you cannot figure out how to not bang your head on the GIL, then for goodness&#x27; sake use Go or Erlang or something that DOES do the one thing you can&#x27;t live without.<p>- - - -<p>Don&#x27;t get me wrong. If this succeeds it will be a great thing. This effort seems well-thought out, and I wish Sam Gross luck and success.

There is so much hate here for the GIL, which is undeserved. You tend to not notice all the nice safety it gives you. If you want to speed up your Python code you could of course try to make it run in parallel: congratulations, you just wasted N times more CPU on slow interpreted code. You could have used an accellerator language like Numba, or write parts of your code in C++ or Rust and get a 10-100 times speedup on a single core!

What about all the scripts and programs that <i>depend</i> on the GIL to give <i>correct results</i> - often without even their authors knowing about it? I guess making this opt-in with a compiler flag is ok, but I would be very, very careful about making it the default. If that ever happens, we will be one Python interpreter upgrade from Y2K-like disaster...

&gt; There was also a large amount of concern from the attendees about the impact the introduction of <i>nogil</i> could have on CPython development. Some worried that introducing <i>nogil</i> mode could mean that the number of tests run in CI would have to double. Others worried that the maintenance burden would significantly increase if two separate versions of CPython were supported simultaneously: one with the GIL, and one without.<p>This seems like a key consideration for the long-term success of <i>nogil</i> and CPython. The Python ecosystem has survived and recovered from past forks but it would good to avoid forks altogether if possible, especially if <i>nogil</i> proves to be stable and performant enough for prime time. At the least we should try to keep any forks short-term, <i>e.g.</i> starting with a compiler flag with a timeline for shifting to a runtime flag. (These are just my thoughts, take everything with a pinch of salt.)

Every conversation on nogil needs to include some dialogue about how it works and what types of changes it requires, both to code and the mental model of the code.<p>I can’t really further consider this or get excited about it unless I understand how it’s going to work and how it addresses previous issues with removimg the Gil.

I love python, but the GIL is IMHO the second worst early design decision ever made right after introducing Null pointers in Java.

in my opinion, getting rid of the GIL is the one thing that Python can do to stave off Julia&#x27;s eventual dominance of numeric computing. Not indefinitely, but by at least 5 years.<p>There are still many cases when data scientists don&#x27;t have a C extension and need to run pure Python functions in parallel, and the GIL makes this an order of magnitude harder (and sometimes slower).<p>I think the core Python devs have gotten rather too conservative in the language&#x27;s old age.

An explanation of GIL and requirements for removing it exists in Python Wiki: <a href="https:&#x2F;&#x2F;wiki.python.org&#x2F;moin&#x2F;GlobalInterpreterLock" rel="nofollow">https:&#x2F;&#x2F;wiki.python.org&#x2F;moin&#x2F;GlobalInterpreterLock</a>

Removing the GIL is surely a breaking change although not exactly a syntactic one. Putting it as Python 4.0 should clear the doubts and allow for widespread release without breaking existing code

What ever happened to PEP 554? I remember reading about that and thinking it was a pretty elegant solution to the GIL. I thought I saw something a while ago about it being expected in an upcoming version, but I see it&#x27;s still in draft.<p><a href="https:&#x2F;&#x2F;peps.python.org&#x2F;pep-0554&#x2F;" rel="nofollow">https:&#x2F;&#x2F;peps.python.org&#x2F;pep-0554&#x2F;</a>

For anyone who wants to test it:<p>docker run -it nogil&#x2F;python

For the change of this magnitude, a compiler flag (default = OFF) is reasonable.<p>Once the extensions and eco-system in general catches-up the flag can be a runtime one (default = OFF)

What does our benevolent dictator has to say about this? It seems to me that it&#x27;s for these kind of undecided situation that we would need one

As someone who only knows Python, this gives me existential angst. Like some other people have pointed out, I think the GIL is secret sauce to Python&#x27;s success. I would be vary of the religious fervor behind taking the GIL to the gallows.<p>It&#x27;s hard to put to words what the GIL does for Python. I think the best I can do is to point to Rust and ask you to consider what Rust&#x27;s number one claim to fame is? A more than significant part of Rust&#x27;s bible (&quot;the book&quot;) is about memory ownership. Python&#x27;s GIL lets me be completely ignorant of these issues and all my brain cells just focus on the problem at hand.<p>My long term livelihood and sanity is at stake here and I really appreciate that some of core maintainers of Python are taking their time and thinking deeply about the implications of removing the GIL.<p>Python with the big bad GIL has become the most popular language in recent years. And it&#x27;s gotten there slowly and steadily over 20 years. The most popular language just so happens to be the only (?) language that is single threaded.

I tend to pick up bad memes like crazy. One I picked up some decades ago is that FP has a useful property in this context: it preserves parallelism to remarkably late in the code, such that you can safely understand the impact of async applied to your code.<p>The lack of first class FP, beyond the type checking stuff, may actually at root be part of the problem: if Python had somehow become the FP rich language it said &quot;nope, different model&quot; -then parallelism and GIL would be a totally different argument.<p>Maybe I was mis-informed. FP interests me but I am not rich in experience. Maybe its an oversold idea?

Sounds like it should be in python4 - that&#x27;s going to break a lot of assumptions...

Why not to just write in Cython?

Come on cpython ... be bold.