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.
Is there any versioning scheme that is comparable? Honest question.
The Changing "Guarantees" Given by Python's Global Interpreter Lock
11–20 of 142 posts
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#12Why 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.
I won't argue with bizzare, but it's common in version notation.
If it wasn't already common, it would probably become common shortly after the first time a big respectable company hit the "oops what comes after 9" problem and decided on dot-separated-integers rather than significant digits :)
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#13Why 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.
Semantic Versioning is ubiquitous across the modern software industry. It’s worth reading about it if you’re not familiar: https://semver.org/
Never assume that version numbers are decimal values. It’s more obvious when you see the full version triple (3.13.0 for example) that it’s not a single number, but the abbreviated version numbers can some times look like a decimal value. You should never compare version numbers as decimals in modern software unless you’re absolutely sure that’s how the project is structured.
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#14these 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…
I'm guessing interleaving is probably not possible because the `extend` call is passed the full list, and it holds the GIL until it's finished. But you'd have to look at the bytecode to be sure, I suppose. If there were three append calls instead of a single extend, I would assume any interleaving would be valid.
> or if the GIL is removed does the interpreter segfault (I'm pretty sure this latter will not be the case for GIL removal but I don't understand the gil remove plan very much yet).
I haven't looked into the plan in detail either, but presumably not, that would be nuts. My understanding is that they're going to replace the GIL with locks on the objects themselves (your list `l` in this case). This is why in all the tests single-threaded performance suffer, you have to take and release more locks if you don't have a GIL, and the objects themselves grow larger as well.
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#15Code 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.
Just because everybody does something the wrong way doesn’t somehow make it magically correct.
One study [1] in the US released in 2020 found almost 90% of people admitted to speeding, but I don’t think anyone would say that speeding is now approved by the authorities and consequence-free.
[1] https://www.thezebra.com/resources/research/speeding-car-ins...
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#16Code 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.
The GIL in an implementation detail of CPython, it's not part of Python the language.
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#17Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#18these 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…
You can probably trigger the behavior of random interleaving even with GIL if you use something other than list or tuple as an argument to list.extend(). CPython special cases list and tuples and copies the contents directly (list_extend_fast() in listobject.c) while it uses iterator for other types (list_extend_iter()).
Because the iterator can be pretty much arbitrary Python code it seems to be a bad idea to guarantee extend() to be atomic, as you don't want to hold the list mutex while calling out into user code.
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#19Code 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.
It depends on what kind of "atomic".
Assuming sequential consistency is pretty broken. Assuming acquire/release atomicity is much more reasonable. Assuming "at least relaxed" is outright mandatory.
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#20Why 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.
Is there any versioning scheme that is comparable? Honest question.
I think kotlin is one example. It uses the same idea but it uses powers of 10 for incremental fixes and numbers for 1 to 9 for hotfixes. That's if for the 3rd number, I do not know what will happen when the second number reaches 2 digits. I guess they will do something to make it comparable again.