Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

stefan-marr.de

Post reply on HN
Print view View original

71–80 of 142 posts

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

#71

Post by klyrs »

yoyohello13 wrote: post #39

It seems like in every python discussion I hear people complain about the GIL. 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.

In my rapidly-approaching-20 years of python development, I have butted heads with the GIL countless times. Are your web apps single-threaded? Have you looked at scaling your service? Or do you use a web framework that handles that for you behind the scenes?

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

#72

Post by coldtea »

throwaway468234 wrote: post #11
coldcode wrote: post #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.

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 incremental numbers as versions. 1, 2, 3, ...

And if we wanted string ordering (as with usual filesystem listing sorting with no extra flags to treat as numbers), we could have fixed length padded parts: 00001.00045.

Not sure if the latter is used, but some software does use the first.

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

#73

Post by continuitylimit »

jerf wrote: post #40
continuitylimit wrote: post #26

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…

While there is some truth in what you are saying, you have a common misunderstanding of the situation. Part of the reason the GIL has proved so difficult to remove is that it is actually a good solution. In fact, there have been multiple largely successful attempts to remove it over time over the entire range of aggressiveness from CPython changes to writing an entire JIT stack (PyPy), but it has never gone in to CPy…

Thanks jerf for your thoughtful reply. tbh I was trolling hn for the very first time in 14 years and based on the response I have a natural talent for it. Who knew. The multi-core point is well taken, as it maps to my own professional experience in that transitional era as well.

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

#74

Post by pdonis »

squeaky-clean wrote: post #56
pdonis wrote: post #54

Earlier quoted context omitted.

> Python doesn't have a full specification This doesn't count? https://docs.python.org/3/reference/index.html

The introduction section states that it's not a complete/exact specification. If you're using a Python implementation and have a question, this should answer it. If you're writing a Python implementation and have a question, this may not answer it. > Consequently, if you were coming from Mars and tried to re-implement Python from this document alone, you might have to guess things and in fact you would probably end u…

> if you were coming from Mars and tried to re-implement Python from this document alone, you might have to guess things and in fact you would probably end up implementing quite a different language

Yes, I know that statement is in the Introduction, but I think it's rather ill-considered. If my implementation is consistent with the language reference, on what grounds would someone claim it was not an implementation of Python but a "different language"?

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

#76

Post by lelanthran »

dfox wrote: post #2

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.

Python doesn't have a standards document. It has a reference implementation that defines the language.

IOW, the python implementation is the standard, and therefore any code that relies on an implementation detail in the reference implementation is, by definition, correct.

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

#77

Post by Kranar »

pdonis wrote: post #52
friendzis wrote: post #42

Earlier quoted context omitted.

AFAIK, there is no Python language specification, therefore implementation details of CPython IMO is the language.

> 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.

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

#78

Post by citrin_ru »

dfox wrote: post #2

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.

A related xkcd: https://xkcd.com/1172/

For a sufficiently popular project there are often cases where users (other projects) rely on existing observed behavior even if it not guaranteed by documentation/specification.

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

#79

Post by citrin_ru »

darklion wrote: post #15
bheadmaster wrote: post #3

Earlier 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...

If 90% are speeding on a given highway / road then the speed limit is likely unreasonably low. Traffic accident which could be prevented by a speed limit typically caused by fastest 10% of the speed distribution, not by remaining 90%.

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

#80

Post by dragonwriter »

pdonis wrote: post #66
dragonwriter wrote: post #58

Earlier quoted context omitted.

I would say that that is intended as documentation for users (includong implementors of tools targeting the language), not a specification for implementors of Python, but I would agree that it is largely usable in either role; my point in the GP was that something distinct called “the Python Language Specification” doesn't exist, but that a (not necessarily complete, from a language implementors perspective) specific…

> 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.

Post reply on HN