The Changing "Guarantees" Given by Python's Global Interpreter Lock • Hacker News Board

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

#111

Post by gnulinux » Fri, Nov 17, 2023, 7:18 PM UTC

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…

> makes me question my s/e belief system

That's a good thing! Models are fit on data, data doesn't fit to models. This is like when people learn elementary music theory then go analyze some actual composer and it doesn't fit the model at all. Well kiddo the problem is that "music theory" is simply a model, a model people created after training some very limit set of musical data, everything outside of that data will probably behave different and you'll have to change your models.

If your software engineering model predicts Python would be unsuccessful, but there is evidence that Python is successful, this simply means your software engineering model is unpredictive and therefore must be revised.

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

#112

Post by coldtea » Fri, Nov 17, 2023, 7:23 PM UTC

usrbinbash wrote: post #105

coldtea wrote: post #72

Earlier quoted context omitted.

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…

Or I could just accept that neither numeric, nor string ordering works for semantic versioning, and write a trivially easy piece of code that does the ordering in a contect where I expect such a scheme. > 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…

>Or I could just accept that neither numeric, nor string ordering works for semantic versioning, and write a trivially easy piece of code that does the ordering in a contect where I expect such a scheme.

Hence the whole "3.10 and 3.9 are perfectly mechanically comparable (meaning one can write a program to deterministically compare them and return their relative order)" part in my comment you perhaps missed.

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

Not that it's any better now with semver though: in practice the semver works 95% of the time, and give just a false sense of comfort at the other 5%. You update, and things still break, despite the semver promise.

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

#113

Post by Kranar » Fri, Nov 17, 2023, 7:24 PM UTC

eesmith wrote: post #97

Kranar wrote: post #70

Earlier quoted context omitted.

Python's semantics do not have a standards document or specification. It's based on its reference implementation (CPython) and different variations of Python even have different semantics (Jython, IronPython, PyPy). The library is documented, and the syntax is also documented, but the semantics themselves are not.

It isn't as dire as you suggest. The language reference at https://docs.python.org/3/reference/index.html "describes the syntax and “core semantics” of the language.". There has been a distinction between Python-the-language and CPython-the-implementation ever since JPython back in the 1990s. For example, reference counting is a CPython implementation details. The reference manual says only: > Objects are never expli…

Absolutely, but note what your very quote says "describes ... the language" rather than "prescribes ... the language".

A standards document or specification's purpose is to "prescribe" how a system shall work in order to be compliant as opposed to a reference which documents how systems currently happen to work.

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

#114

Post by pdonis » Fri, Nov 17, 2023, 7:25 PM UTC

uxp8u61q wrote: post #90

pdonis wrote: post #74

Earlier quoted context omitted.

> 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 o…

On the grounds that we live in the real world, not a world where anything written down is a true and complete description of reality. "Technically correct" is sometimes a synonym of "incorrect".

By your criterion, no programming language has a language specification at all. I don't think that's a useful way to look at things.

I would like to see some indication from the people who say that the Python Language Reference I gave a link to does not qualify as "language specification", of what would qualify. Specific examples would be nice.

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

#115

Post by pdonis » Fri, Nov 17, 2023, 7:26 PM UTC

dragonwriter wrote: post #80

pdonis wrote: post #66

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.

> we rather explicitly agree that Python has nothing called a “language specification”

No, we don't. I have already said explicitly that I think the Python Language Reference is such a thing. (I am ignoring quibbles about it being called a "reference" instead of a "specification".) If you think it isn't, why? What does count as a "language specification" in your view? Do you have any specific examples that you can contrast with Python?

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

#116

Post by pdonis » Fri, Nov 17, 2023, 7:29 PM UTC

Kranar wrote: post #77

pdonis wrote: post #52

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.

> That is not a specification.

You're quibbling. By your definition, no programming language has a "specification". Every language has implementations that do things that aren't explicitly described in any document.

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

#117

Post by Kranar » Fri, Nov 17, 2023, 7:29 PM UTC

eesmith wrote: post #107

Kranar wrote: post #77

Earlier quoted context omitted.

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.

What advantages would there be to that document? 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 possi…

I never mentioned any advantage or disadvantage. I am only stating a fact about the current state of Python.

Python does not have a specification or a standards document, it has a reference that describes how Python happens to work and the reference is a great resource for people to familiarize themselves with the language but it should simply be clear that its purpose is to reflect the existing state of the language rather than to specify how Python works.

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

#118

Post by Kranar » Fri, Nov 17, 2023, 7:30 PM UTC

pdonis wrote: post #116

Kranar wrote: post #77

Earlier quoted context omitted.

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.

> That is not a specification. You're quibbling. By your definition, no programming language has a "specification". Every language has implementations that do things that aren't explicitly described in any document.

Plenty of languages have a specification. C++, Java, C# all do.

Some languages do not, such as Python and Rust.

The ISO C++ committee even uses quite strong language about the C++ standard and makes it a point to differentiate between the C++ specification and C++ references:

>The standard is not intended to teach how to use C++. Rather, it is an international treaty – a formal, legal, and sometimes mind-numbingly detailed technical document intended primarily for people writing C++ compilers and standard library implementations.

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

#119

Post by pdonis » Fri, Nov 17, 2023, 7:32 PM UTC

Kranar wrote: post #117

eesmith wrote: post #107

Earlier quoted context omitted.

What advantages would there be to that document? 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 possi…

I never mentioned any advantage or disadvantage. I am only stating a fact about the current state of Python. Python does not have a specification or a standards document, it has a reference that describes how Python happens to work and the reference is a great resource for people to familiarize themselves with the language but it should simply be clear that its purpose is to reflect the existing state of the language…

Then why are different implementations of Python all implementations of Python? What makes them implementations of Python rather than different languages?

I've already given my answer: they all meet the language reference I linked to (yes, the word "reference" appears in its title, not "specification"; that's just another quibble).

What is your answer?

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

#120

Post by pdonis » Fri, Nov 17, 2023, 7:33 PM UTC

Kranar wrote: post #118

pdonis wrote: post #116

Earlier quoted context omitted.

> That is not a specification. You're quibbling. By your definition, no programming language has a "specification". Every language has implementations that do things that aren't explicitly described in any document.

Plenty of languages have a specification. C++, Java, C# all do. Some languages do not, such as Python and Rust. The ISO C++ committee even uses quite strong language about the C++ standard and makes it a point to differentiate between the C++ specification and C++ references: >The standard is not intended to teach how to use C++. Rather, it is an international treaty – a formal, legal, and sometimes mind-numbingly de…

Does every C++ implementation do exactly what is in the C++ language specification, no more, no less?

Same question for Java and C#.

If the answer to all of these questions is "no", as I believe it is, on what grounds do you claim that these languages have a specification, while Python and Rust do not?