Earlier quoted context omitted.
Is there any versioning scheme that is comparable? Honest question.
Some languages just use integer versions, like Java.
The early versions did not use integers, for what it's worth.
The Changing "Guarantees" Given by Python's Global Interpreter Lock
41–50 of 142 posts
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#42Earlier quoted context omitted.
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.
AFAIK, there is no Python language specification, therefore implementation details of CPython IMO is the language.
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#43Earlier quoted context omitted.
I dunno about that. There's a lot of Python out there with worker threads dumping their output into a shared "results" dict on the assumption that those insert operations are atomic.
Relying on implementation behavior, even if it’s very visible and hasn’t changed for a few decades, is morally wrong and reprehensible. Only the letter of the standard has any bearing on correct reality.
> morally wrong
That's a wild one
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#44The 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/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. Is there no great architect in the sky? Is there no software god after all, looking down, punishing sloppy engineers and granting blessi…
How is this sloppy engineering? And no of course there is no grand architect, orchestrating everything neatly form a central place of command, instead everything is an emergent process including the decisions made by the python team.
What are you even complaining about? What is your point?
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#45Earlier quoted context omitted.
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...
Speeding absolutely is approved by the authorities and consequence free where I live.
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#46The 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/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. Is there no great architect in the sky? Is there no software god after all, looking down, punishing sloppy engineers and granting blessi…
Tools win not because they are "better" in some platonic ideal of a programming language but because they are more practical for solving the problems people have.
Python, JS, C, Bash aren't even particularly great at the problems they solve, but they succeed mostly on inertia (it's where all the libraries are, it's what people know) and occupying developer mindshare.
They are full of obvious design mistakes; things that not even the creators of the language (nor any of its users) can defend, yet those languages are used infinitely more than languages that eschew those mistakes. Why? Because they solve problems people have.
If this sounds terrible to you, the good news is that there is a tonne of low-hanging fruit in the programming language design space. Consider that most developers know nothing of sum-types, or eschew the idea of typing entirely. Consider that most developers see no fundamental problem behind having to venv or dockerise software lest it bitrot over a month. Consider that programmers actually use bash.
These terrible, obviously broken tools are somehow the most pragmatic things we actually have. The fruit is low-hanging; the door is wide open, if you wish to grab it.
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#47these 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 will always get either [1,2,3,4,5,6] or [4,5,6,1,2,3] in the upcoming `--disable-gil` builds of CPython 3.13 and the nogil forks. Most operations on mutable collections hold a per-object lock. Part of the integration work will be to better document the thread-safety guarantees, but there is still a lot of work to do before we get there.
Every mutable collection needs to lock before write? Sounds slow af
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#48Earlier quoted context omitted.
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...
> Just because everybody does something the wrong way doesn’t somehow make it magically correct. Depends on the definition of "correct". One way to define "correct" is "as defined by the standard". However, standard serves a purpose - to maintain interoperability between components, so the other, deeper, way to define "correct" is "interoperable with the ecosystem". The official standard can argue that relying on the…
Lest we forget that Python doesn't even have a language standard.
The "standard" is a combination of PEPs, the Python docs, and the CPython implementation.
Implementation details are language features, because implementation details are the standard. Python programs that rely on the GIL are not "wrong". Such programs are relying on clearly-documented features of the system that they use.
Is it "wrong" to use GCC-specific features in a C program, if you know that you only intend to target GCC?
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#49How 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?
Thusly moving to multiprocessing and dealing with the lack of shared memory issues, with managers.
When/if the GIL goes away, good riddence.
Re: The Changing "Guarantees" Given by Python's Global Interpreter Lock
#50Earlier quoted context omitted.
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.
There is no language standard. The GIL is a Python language feature because it's a CPython feature.