The Changing "Guarantees" Given by Python's Global Interpreter Lock

Code that assumes that something is going to be atomic because of the GIL (or any other implementation detail) is simply broken. If you need something to be atomic you should be explicit about that and use mutex or something.

these examples of &quot;what one would assume to be atomic&quot; did not seem useful to me, they looked like things that are obviously not threadsafe.<p>a more interesting example is something like this:<p><pre><code> # setup l = [] # thread A l.extend([1, 2, 3]) # thread B l.extend([4, 5, 6]) </code></pre> is the resulting list always within the set of [1,2,3,4,5,6] or [4,5,6,1,2,3] ? or are the two sets of numbers randomly interleaved in the list? or if the GIL is removed does the interpreter segfault (I&#x27;m pretty sure this latter will not be the case for GIL removal but I don&#x27;t understand the gil remove plan very much yet).<p>Edit: before people jump in and correct how the above is a bad idea anyway, it&#x27;s not like I&#x27;d ever do the above and expect anything but disaster. This is more of a thought experiment to understand what GIL removal is going to do.

&gt;&gt; I have at least one very concrete example of code that someone assumed to be atomic:<p>request_id = self._next_id<p>self._next_id += 1<p>To think that is thread safe is just naive. Once you understand the potential problem you can look at the code and ask &quot;why shouldn&#x27;t this be unsafe?&quot; Since there is nothing explicitly preventing the problem. After reading TFA (lazily I admit) I still don&#x27;t know why that code is thread-safe with the GIL.<p>Python is fun and often forgiving, but a bunch of people who got lucky (because they were never taught about the hazards) are going to learn some new stuff with no-gil. I think it&#x27;s a long overdue change and worth the (single thread) performance hit and bug surfacing phase.

It seems like in every python discussion I hear people complain about the GIL.<p>I’m happy people are working on removing the GIL, but As a professional python dev for about 5 years now I have literally never had a problem where the GIL was a limiter. Although I just make web apps so maybe I’m not the target audience.

Pythons threading and GC model has always been problematic on multi-core architectures.<p>It shouldn&#x27;t be anywhere near time-critical and or low-latency use-cases.<p>Python is functionally the modern BASIC, and included many of the same design trade-offs for usability.<p>Don&#x27;t get mad, it is true... and we know it. =)

How many other people knew nothing about the GIL. Got to using threading and inevitably found major performance issues that were 100% caused by the GIL?<p>Thusly moving to multiprocessing and dealing with the lack of shared memory issues, with managers.<p>When&#x2F;if the GIL goes away, good riddence.

Yet more evidence that removing the GIL really ought to bump the major version to Python 4.

Why does Python use an un-comparable version number scheme? Not being a Python programmer, comparing version 3.9 to 3.13 seemed bizarre until I caught on.

The brief blurb about how GIL came to be, in light of Python’s success as a language and a tool, makes me question my s&#x2F;e belief system. Things like this are like when good things happen to bad people and bad things happen to good people. It makes you question the meaning of it all.<p>Is there no great architect in the sky? Is there no software god after all, looking down, punishing sloppy engineers and granting blessings to thoughtful engineers? How else to explain this injustice of sloppy engineering eating the world (to say nothing of JavaScript)?