Chris Angelico writes: > Can you explain what would be improved by having a formalized > standard?
The Language Reference together with the Library Reference *already* constitute a formalized standard. They are at least as precise as most W3C or IETF standards. What you and Dan seem to be referring to is a standard sanctioned by a major, preferably international, umbrella standards organization. But in fact a standard is just a sufficiently precise specification that allows multiple independent implementations to achieve the same results, and is accepted by more than one implementer. > So far this thread has just been vague ideas that a bureaucratic > procedure will somehow help things, without showing a problem. Python *has* a bureaucratic procedure, it's called "the PEP process". It's true that the standard library accretes a lot of small changes without PEPs, but usually any conformant implementation can compile (or whatever) them without change because they're implemented in (*gasp*!) Standard Python of the same version. And they must be documented (ie, made part of the Reference), or the merge request will not be accepted. We now even have a full-on bureacracy (the Steering Council, sorry folks, but that's what you are). The main difference between the Python PEP process and the standardization processes of international bodies such as ECMA, ISO, W3C, and IETF is the Code of Conduct leading to much more civil discussions, and the lack of interest[1] of corporations in getting their patented tech sanctioned in it[2]. There's also the procedural facts that (1) Python really produces only one standard (no need for an umbrella organization to police the working committees), and (2) there is no formal voting procedure to permit log-rolling by such special interests. But I see no need for one, given the trust the community had in Guido (sorry for the name check, Guido, but it's true you know) and now in the Steering Council.[3] The voting procedures in other bodies are required because many of the participants mistrust each other. However, a standard should be judged by its content, not the formality (or lack of it) of the standardization process. Dan Stromberg points to potential issues with a reference implementation. But by definition, a *reference* implementation implements a standard. This is only a problem if the standard is sufficiently sloppy that the only way to determine conformance of an alternative implementation is by comparing behavior to the reference implementation. But that's not a problem with reference implementations, that's a problem with the particular standard. It's true that frequently it's (much) more convenient to ask your friendly neighborhood Python interpreter what some expression does than to try to figure it out from the reference (David Beazley has made a PyCon speaking career out of such oddities!), but that's a *benefit* of the reference implementation, not a problem. There's another kind of standard, where the "reference" implementation *is* the standard.[4] If the docs differ from the implementation, you change the docs. That's *not true* (in principle) for Python, except that fairly often where the docs are ambiguous and it matters, the standard will be amended in the next version to conform to CPython's behavior. However, where the behavior of CPython contradicts the references, that's considered to be a bug to be fixed. Amending the docs in those cases does happen, but it's controversial and needs to be supported by showing that the implementation behavior is depended on by applications in the wild. Also note the characterization of CPython in https://en.wikipedia.org/wiki/Reference_implementation. (I didn't check to see if a Pythonista were the most recent editor tho. ;-) Steve Footnotes: [1] Or perhaps their recognition that it's a no-go and not worth their effort. [2] Even there, occasionally powerful core developers have been able to push through features they wanted for $DAYJOB (async and type hints, I'm looking at you). Those would have been major firefights in the absence of trust. [3] Case in point: The pattern-matching PEPs are controversial, but note that *nobody* has questioned the legitimacy of the SC, only its judgment, when questioning the approval of that series of PEPs. And the general reaction has been "great, now we can move on with it!", as far as I can tell. [4] I'm pretty sure there's a different term for such implementations but for the life of me I can't remember it. Or it's possible that "reference implementation" was the right term for "the implementation is the standard", and the meaning has changed since nobody does that any more (or at least nobody with a shred of pride is willing to admit it). Anyway, now the accepted meaning of reference implementation is that it is an implementation that satisfies all requirements of the (separate) standard. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GCFOLVSRUB3KZL37O5EOLFXXGQQKLP5X/ Code of Conduct: http://python.org/psf/codeofconduct/
