101–110 of 142 posts
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.
The gil is a feature. Not using a feature that makes sense in our context is counter productive.
It's an implementation detail, and relying on those for functionality is a great way of getting ones code to break.
Earlier quoted context omitted.
> not a specification for implementors of Python I don't see why not. The "Introduction" section specifically mentions different implementations and distinguishes implementation details, which can vary by implementation, from the language reference itself, which defines what every implementation has to meet to be considered an implementation of the Python language. > my point in the GP was that something distinct cal…
So, we rather explicitly agree that Python has nothing called a “language specification”, but that its published first party documentation includes what is, functionally, a specification of the language distinct from CPython implementation details? Not sure why there is an argument here.
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.
True, but when a majority of ecosystem is relying on an implementation detail, that implementation detail becomes de-facto standard.
e.g.; there are C-compilers that usually zero most allocated structures. That's an implementation detail however, not a feature of C. C doesn't guarantee you zeroed memory anywhere, and code that assumes otherwise is just one compilation away from a desaster.
Earlier quoted context omitted.
> 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-spec…
The problem here is: Implementation details are not guaranteed to be stable. They can change with every release.
So if I write code that relies on any particular implementation detail, it may be correct today, and may be wrong two weeks from now, even though I didn't change anything.
Earlier quoted context omitted.
Is there any versioning scheme that is comparable? Honest question.
Comparable as what? 3.10 and 3.9 are perfectly mechanically comparable (meaning one can write a program to deterministically compare them and return their relative order), just not with default numeric ordering (then again they're not numbers, they are composite values that are comprised by numbers) or naive string based ordering. If we wanted trivially comparable with regular numeric ordering we could have increment…
> If we wanted trivially comparable with regular numeric ordering we could have incremental numbers as versions. 1, 2, 3, ...
Yes, and then we would be back to the day when the version number gave me zero information about what changed, and how that affects compatibility with existing code.
There is a reason semver is used across the industry by now.
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/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 t…
I would argue the "problem" that Python really solves is the amount of engineering effort required to read and write code for common software use cases. Ie, it's purpose is to help developers write better code faster and easier than other languages, while execution speed has usually had a lower priority. In that framing, it's great at solving the problem of development time and old code being hard to maintain, and that's why so many engineers like myself love it.
Earlier quoted context omitted.
> AFAIK, there is no Python language specification Yes, there is: https://docs.python.org/3/reference/index.html This specification does not mention the GIL anywhere, which means it is, as the GP said, an implementation detail. Other implementations of Python that do not have the GIL are still "Python" implementations because they meet this language specification.
That is not a specification. A specification is a prescriptive document of how a system is required to work whereas a reference is a descriptive document of how a system happens to currently work. Python has a reference, in fact it has many references that even contradict one another in subtle ways, but it does not have a specification.
I mean, I can see the point if there are multiple commercial competitors in the market, as there is with C/C++, or if the implementation is proprietary and the users want to avoid vendor lock-in.
But the Minimal BASIC of ANSI X3.60-1978 never did catch on for any of the BASICs I used in the 1990s, and the Full BASIC of ANSI X3.113-1987 was a flop, so clearly it's possible to put a lot of time into a standard only to have it be irrelevant.
Earlier quoted context omitted.
Every mutable collection needs to lock before write? Sounds slow af
Locks are generally very cheap if they're not contended. Of course it's all relative though!
It shouldn't be anywhere near time-critical and or low-latency use-cases.
Python is functionally the modern BASIC, and included many of the same design trade-offs for usability.
Don't get mad, it is true... and we know it. =)