The Changing "Guarantees" Given by Python's Global Interpreter Lock
1–10 of 142 posts
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#2Code 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.
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#3Code 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.
True, but when a majority of ecosystem is relying on an implementation detail, that implementation detail becomes de-facto standard.
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#4Why 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.
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#5Why 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.
Sem ver is pretty standard imo.
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#6Code 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.
The gil is a feature. Not using a feature that makes sense in our context is counter productive.
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#7Why 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.
Like in most versioning schemes, the dot isn't meant to be read as decimal point.
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#8Why 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.
comparing version numbers as tuples and not as decimals is a pretty standard thing. Linux does it as well, for example. I am actually not sure of a project which does something different.
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#9these examples of "what one would assume to be atomic" did not seem useful to me, they looked like things that are obviously not threadsafe.
a more interesting example is something like this:
# setup
l = []
# thread A
l.extend([1, 2, 3])
# thread B
l.extend([4, 5, 6])
Edit: before people jump in and correct how the above is a bad idea anyway, it's not like I'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.
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#10these examples of "what one would assume to be atomic" did not seem useful to me, they looked like things that are obviously not threadsafe. a more interesting example is something like this: # setup l = [] # thread A l.extend([1, 2, 3]) # thread B l.extend([4, 5, 6]) 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…
It’ll be guarded by a fine-grained mutex, so it won’t seg fault. They’re using a performant mutex based on webkit’s wtf::lock.