5 ms·

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

by Kranar 3y ago

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.

eesmith 3y ago
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 possible to put a lot of time into a standard only to have it be irrelevant.
- Kranar 3y ago
  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.
  - pdonis 3y ago
    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?
    - Kranar 3y ago
      Haha, no they don't all meet the language reference you linked to and if you used them you'd know that! Python is a lot more like LISP than it is C++. There are many flavors of Python, from MicroPython to GraalPython to Cyston and literally dozens of them. They most certainly do not all meet the language reference you linked to and they all have quirks here and there. A language does not need a specification in order to exist or to have a name. What matters is that people use it and get work done with it, and ultimately if looks like a Python and quacks like a Python, then it's fine to call it a Python.
      - deleted 3y ago
        [deleted]
  - eesmith 3y ago
    What then did you think it relevant to point out that Python does not have a prescriptive document if you didn't think it was somehow useful? Here's another fact: Python doesn't have its own typeface either. Yet that fact is hardly germane to the thread. A prescriptive document is a formal specification. The Python Language Reference is a less formal specification. It's still a specification. It is also not a single document, but then again even a formal specification may incorporate other specifications by reference.
    - Kranar 3y ago
      Because the original comment was about the appropriateness of writing Python code according to the reference implementation as opposed to writing Python code strictly according to the reference document. Some people are arguing that the reference documentation is in some sense authoritative and the only resource that should be used to define Python's semantics. In particular the issue at hand is whether the GIL is a part of the semantics of a Python program. As my position is that the CPython implementation is the reference implementation for Python and as the GIL is an integral part of that implementation, then the GIL does form a part of Python's semantics regardless of whether the reference documentation mentions it or not. The Python reference documentation is not a specification and it's not intended to be one.
pdonis 3y ago
> 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.
- Kranar 3y ago
  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.
  - pdonis 3y ago
    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?
    - Kranar 3y ago
      Yes the C++ and Java implementations do exactly what is in the language specification. The C++ specification explicitly allows languages to do more, but it can not do less. I believe Java has a similar clause but I'm not sure. The grounds that I claim is that you can read them, here they are: https://docs.oracle.com/javase/specs/ https://docs.oracle.com/javase/specs/ https://isocpp.org/files/papers/N4860.pdf https://isocpp.org/files/papers/N4860.pdf Note what the actual C++ standard states, and I quote: >This document specifies requirements for implementations of the C++ programming language. The first such requirement is that they implement the language, so this document also defines C++. Other requirements and relaxations of the first requirement appear at various places within this document
samus 3y ago
Whether it is a specification or a reference doesn't really matter for this discussion. What matters is that it is the closest thing to a specification that exists for Python. Assuming anything beyond it ties the program to internals of a specific implementation. Internals for which the vendor might have different intentions about keeping stable or change than users expect.
- Kranar 3y ago
  It's absolutely pertinent to this discussion, this whole discussion is about whether the GIL is part of the semantics of a Python program or not. My position is that it is because the GIL is a part of the CPython reference implementation. Others object saying that the Python reference document is what specifies its semantics, not the reference implementation. My position is that both the CPython reference implementation and the reference documentation are valid sources that document Python's semantics and that they both can and should be used.
  - samus 3y ago
    Both of the former provide stronger promises about how likely changes in the future are. For the former, user input and coordination is absolutely required. Implementation details are documented to allow performance optimizations and to give insight into why certain things are how they are. Therefore, users can reasonably expect that the vendor won't cause performance regressions for existing code. However, it is unwise to derive semantics from them, even if they are technically documented in that way. One of the biggest disadvantages of relying on implementation details is that it makes it way more troublesome for the vendor to maintain and improve the product. Anyways, the GIL and the presence of possible concurrency bugs are completely orthogonal things as the GIL has always only served to prevent corruption of runtime data structures, not of user code.
  - pdonis 3y ago
    > this whole discussion is about whether the GIL is part of the semantics of a Python program or not. My position is that it is because the GIL is a part of the CPython reference implementation. And my position is that it is not because there are other implementations of Python that do not have it, and which everybody agrees are implementations of Python. Not only that, but the very language reference that I linked to explicitly distinguishes CPython implementation details from the language itself. So the Python dev team does not appear to agree with your position.

by Kranar 3y ago

eesmith 3y ago

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 possible to put a lot of time into a standard only to have it be irrelevant.

Kranar 3y ago
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.
- pdonis 3y ago
  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?
  - Kranar 3y ago
    Haha, no they don't all meet the language reference you linked to and if you used them you'd know that! Python is a lot more like LISP than it is C++. There are many flavors of Python, from MicroPython to GraalPython to Cyston and literally dozens of them. They most certainly do not all meet the language reference you linked to and they all have quirks here and there. A language does not need a specification in order to exist or to have a name. What matters is that people use it and get work done with it, and ultimately if looks like a Python and quacks like a Python, then it's fine to call it a Python.
    - deleted 3y ago
      [deleted]
- eesmith 3y ago
  What then did you think it relevant to point out that Python does not have a prescriptive document if you didn't think it was somehow useful? Here's another fact: Python doesn't have its own typeface either. Yet that fact is hardly germane to the thread. A prescriptive document is a formal specification. The Python Language Reference is a less formal specification. It's still a specification. It is also not a single document, but then again even a formal specification may incorporate other specifications by reference.
  - Kranar 3y ago
    Because the original comment was about the appropriateness of writing Python code according to the reference implementation as opposed to writing Python code strictly according to the reference document. Some people are arguing that the reference documentation is in some sense authoritative and the only resource that should be used to define Python's semantics. In particular the issue at hand is whether the GIL is a part of the semantics of a Python program. As my position is that the CPython implementation is the reference implementation for Python and as the GIL is an integral part of that implementation, then the GIL does form a part of Python's semantics regardless of whether the reference documentation mentions it or not. The Python reference documentation is not a specification and it's not intended to be one.

pdonis 3y ago

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

Kranar 3y ago
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.
- pdonis 3y ago
  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?
  - Kranar 3y ago
    Yes the C++ and Java implementations do exactly what is in the language specification. The C++ specification explicitly allows languages to do more, but it can not do less. I believe Java has a similar clause but I'm not sure. The grounds that I claim is that you can read them, here they are: https://docs.oracle.com/javase/specs/ https://docs.oracle.com/javase/specs/ https://isocpp.org/files/papers/N4860.pdf https://isocpp.org/files/papers/N4860.pdf Note what the actual C++ standard states, and I quote: >This document specifies requirements for implementations of the C++ programming language. The first such requirement is that they implement the language, so this document also defines C++. Other requirements and relaxations of the first requirement appear at various places within this document

samus 3y ago

Whether it is a specification or a reference doesn't really matter for this discussion. What matters is that it is the closest thing to a specification that exists for Python. Assuming anything beyond it ties the program to internals of a specific implementation. Internals for which the vendor might have different intentions about keeping stable or change than users expect.

Kranar 3y ago
It's absolutely pertinent to this discussion, this whole discussion is about whether the GIL is part of the semantics of a Python program or not. My position is that it is because the GIL is a part of the CPython reference implementation. Others object saying that the Python reference document is what specifies its semantics, not the reference implementation. My position is that both the CPython reference implementation and the reference documentation are valid sources that document Python's semantics and that they both can and should be used.
- samus 3y ago
  Both of the former provide stronger promises about how likely changes in the future are. For the former, user input and coordination is absolutely required. Implementation details are documented to allow performance optimizations and to give insight into why certain things are how they are. Therefore, users can reasonably expect that the vendor won't cause performance regressions for existing code. However, it is unwise to derive semantics from them, even if they are technically documented in that way. One of the biggest disadvantages of relying on implementation details is that it makes it way more troublesome for the vendor to maintain and improve the product. Anyways, the GIL and the presence of possible concurrency bugs are completely orthogonal things as the GIL has always only served to prevent corruption of runtime data structures, not of user code.
- pdonis 3y ago
  > this whole discussion is about whether the GIL is part of the semantics of a Python program or not. My position is that it is because the GIL is a part of the CPython reference implementation. And my position is that it is not because there are other implementations of Python that do not have it, and which everybody agrees are implementations of Python. Not only that, but the very language reference that I linked to explicitly distinguishes CPython implementation details from the language itself. So the Python dev team does not appear to agree with your position.