On Fri, Feb 12, 2021 at 10:51 AM Paul Bryan <pbryan@anode.ca> wrote:

From my point of view, the process of standardizing through a formal standards body is a tedious, verbose, laborious, bureaucratic and often contentious process.

I've never participated in such a standardization, but I'm sure it's hard work. I'd really like to know quantitatively what the benefits would be of

running that gauntlet, as I'm not sure they would outweigh the costs.

I think it'd be easier to quantify love. On Fri, 2021-02-12 at 10:33 -0800, Dan Stromberg wrote:

What would it take to create an ANSI, ECMA and/or ISO standard for Python?

It seems to have really helped C.

It looks like Java isn't standardized, and it's done OK, though perhaps it was healthier in the past - before Oracle decided API's were ownable.

I think standardizing Python might be really good for controlling its growth and avoiding featuritis.

_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/JZYW4JOT... Code of Conduct: http://python.org/psf/codeofconduct/

On Fri, Feb 12, 2021 at 11:02 AM Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote:

How a standard by ANSI, ECMA and/or ISO is any better than a standard by the PSF?

I don't think what the PSF is producing is truly a standard.

Is PSF bad at "controlling its growth and avoiding featuritis" in your opinion or smth?

It's not the PSF I have an issue with. It's having a reference implementation. I think the PSF has done a pretty good job of keeping in mind what other Python implementations can realistically do also - but doing so is an uphill battle. I believe Python needs to become more independent of CPython, for Python's long term health. Think of C. Where would it be if it had K&R C as a reference implementation, long term? There are dozens, maybe hundreds of mostly-compatible implementations of C. I think this should be Python's goal. Look where not having a standard got Perl. It is so defined by a single implementation that the language is collapsing under its own weight. Perl 6 is so not-perl that it was renamed. Python is much less guilty of exuberant design, that's part of what I like about Python, but like I said, having a reference implementation instead of a standard makes that more difficult.

On 12.02.2021 21:33, Dan Stromberg wrote:

What would it take to create an ANSI, ECMA and/or ISO standard for Python?

It seems to have really helped C.

It looks like Java isn't standardized, and it's done OK, though perhaps it was healthier in the past - before Oracle decided API's were ownable.

I think standardizing Python might be really good for controlling its growth and avoiding featuritis.

_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.orghttps://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JZYW4JOT... Code of Conduct: http://python.org/psf/codeofconduct/

-- Regards, Ivan

_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/ZBKXMHWF... Code of Conduct: http://python.org/psf/codeofconduct/

That could be good. :) And sometimes standards are rubber stamped by other bodies. On Fri, Feb 12, 2021 at 12:03 PM Paul Bryan <pbryan@anode.ca> wrote:

What if PSF were to undertake codifying a language specification?

On Fri, 2021-02-12 at 11:57 -0800, Dan Stromberg wrote:

On Fri, Feb 12, 2021 at 11:02 AM Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote:

How a standard by ANSI, ECMA and/or ISO is any better than a standard by the PSF?

I don't think what the PSF is producing is truly a standard.

Is PSF bad at "controlling its growth and avoiding featuritis" in your opinion or smth?

It's not the PSF I have an issue with. It's having a reference implementation.

I think the PSF has done a pretty good job of keeping in mind what other Python implementations can realistically do also - but doing so is an uphill battle.

I believe Python needs to become more independent of CPython, for Python's long term health.

Think of C. Where would it be if it had K&R C as a reference implementation, long term? There are dozens, maybe hundreds of mostly-compatible implementations of C. I think this should be Python's goal.

Look where not having a standard got Perl. It is so defined by a single implementation that the language is collapsing under its own weight. Perl 6 is so not-perl that it was renamed. Python is much less guilty of exuberant design, that's part of what I like about Python, but like I said, having a reference implementation instead of a standard makes that more difficult.

On 12.02.2021 21:33, Dan Stromberg wrote:

What would it take to create an ANSI, ECMA and/or ISO standard for Python?

It seems to have really helped C.

It looks like Java isn't standardized, and it's done OK, though perhaps it was healthier in the past - before Oracle decided API's were ownable.

I think standardizing Python might be really good for controlling its growth and avoiding featuritis.

_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.orghttps://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JZYW4JOT... Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/7WXKZFTL... Code of Conduct: http://python.org/psf/codeofconduct/

I definitely think they could. As a developer using Python, they're fully sufficient for my purposes. I honestly don't know enough about non-CPython implementations and their challenges to know what gaps (if any) would need to be filled to fully implement a compatible version. On Sat, 2021-02-13 at 10:58 +1300, Greg Ewing wrote:

On 13/02/21 9:03 am, Paul Bryan wrote:

...

What if PSF were to undertake codifying a language specification?

We have the Language Reference and Library Reference. Do they not count as specifications?

On Sat, Feb 13, 2021 at 6:58 AM Dan Stromberg <drsalists@gmail.com> wrote:

I believe Python needs to become more independent of CPython, for Python's long term health.

Since 1997, Python has been defined independently of CPython. There are numerous documents that define the language semantics for the benefit of other implementations. Multiple implementations have somehow managed to exist without any sort of ISO standard. Can you explain what would be improved by having a formalized standard? So far this thread has just been vague ideas that a bureaucratic procedure will somehow help things, without showing a problem. ChrisA

On Sat, Feb 13, 2021 at 10:42 AM Dan Stromberg <drsalists@gmail.com> wrote:

On Fri, Feb 12, 2021 at 2:26 PM Chris Angelico <rosuav@gmail.com> wrote:

...

On Sat, Feb 13, 2021 at 6:58 AM Dan Stromberg <drsalists@gmail.com> wrote:

...

I believe Python needs to become more independent of CPython, for Python's long term health.

Since 1997, Python has been defined independently of CPython.

Really? It sounds like I missed something important then. More specifically, what changed in 1997?

Jython launched. I may have the year wrong, but it was about then, and that's what Wikipedia says. The significance may have happened +/- a year of that, I'm not sure, but the point is that that's when effort started to be made to separate CPython from Python - allowing Jython to know the language semantics.

...

There are numerous documents that define the language semantics for the benefit of other implementations.

References please? I'd love to find out this has already been done.

Mostly, the reference documentation. Anything that says how to use something is also the definition of how to implement it.

...

Multiple implementations have somehow managed to exist without any sort of ISO standard.

Yes, the existence of a small number of other implementations (modulo web implementations) is why I say Python has done pretty well despite the existence of a reference implementation,

...

Can you explain what would be improved by having a formalized standard?

It's mostly about avoiding creeping featurism and painting other implementations into corners. Or - and this is equally important - leaving other implementations in the dust.

Other implementations can still be left in the dust even if there's a standard - just look at various other languages, standards and all, and the difficulties of using standardized features across compilers. (I'm not naming names, here, but cross-platform C code is harder than it needs to be.)

Consider how far back Jython and IronPython are. If the "bureaucracy" (I see it as measured progress) of a standard would allow them to catch up, without having to study the CPython source code, the standard will have done its job.

Is studying the CPython source code what's keeping them back? Do you have any evidence to support that?

In all candor, I do not think that frequent releases with significant new features in each are good for a language. I'll remind you that the complexity of a language varies with the square of its feature count.

There's probably been a rush to add features in the wake of the 2.x-to-3.x transition, but hopefully we won't be continuing at that pace.

I, on the other hand, am very happy to have new features in the language. Each year, Python grows better. If you don't like that, you're welcome to continue to use Python 3.5 and define that as your standard; I believe that, for instance, MicroPython has chosen a fixed standard to aim for.

And again: a good language has a small core but is extensible, enabling extensive /libraries/. Python is indeed nicely extensible.

Sure, and I've worked with languages that aren't easily extensible. But there are language features too. Hamstringing the language is not helping anyone.

...

So far this thread has just been vague ideas that a bureaucratic procedure will somehow help things, without showing a problem.

I've outlined some, but you seem more than ready to dismiss them.

You've shown what MIGHT be a problem, but you haven't actually shown any real problems.

The things that got me thinking about this were: 1) The caution my comparative languages professor in school delivered about reference implementations and how bad they can be for a language's maturation. 2) A comment on python-list about languages without standards not being grown up, that I really couldn't disagree with. 3) The common confusion between "Python" and "CPython". Many people still think they're the same thing.

Please elaborate on the first two. The third one won't change even with a standard. If reference implementations are bad, why do so many things - not just languages - have them? There are reference implementations for crypto algorithms, for example. Do they hurt those algorithms? The comment on python-list is, just like your post, lacking in substantiation. In fact, I would call it nothing but FUD.

Of course, Java is grown up and it has no formal standard. But there's always Perl's scary example lurking in the background. And even Java really doesn't appear to have that many competing implementations. I'm aware of the IBM JDK, OpenJDK, and gcj. But for all Java's success, there probably should be (have been) more.

And having a comprehensive test suite can help a lot too - it sounds like we're pretty close there? ISTR hearing that Pypy was able to reuse much of CPython's test suite. Having a generic test suite that isn't tied to a specific implementation would be fantastic. One could argue this is what has given rise to the alternative implementations of Python we have. Unless you count the ones that run in a web browser - there were at least 32 at my last count, with frequently-superficial compatibility.

Yes, CPython's test suite is extensive and extremely useful.

But we really should encourage more compatible implementations. That's what I'm trying to get at. That's probably the main "problem" you seem to want me to highlight, even though I'd rather not be very critical.

By "encourage", what do you mean? There are quite a few of them around already. Are you saying that they're unable to do anything because Python lacks an ISO standard? Please show how that would change with one. Every time there is a specific example of a conflict between CPython and the reference documentation, it is dealt with (as a bug). Every time there's an ambiguity, it is dealt with (often by documenting things more clearly - eg PEP 558). That's why I'm asking you to show actual problems, not theoretical ones; actual problems can be solved, theoretical problems are only really good for FUD. ChrisA

From talking to people who at various times have participated in a language standardization process, I've learned that it's not a panacea, it's an enormous amount of work, it doesn't guarantee a good outcome, and plenty of languages do just fine without it. Also, it costs real money. A lot. I have no interest in going that route, and I don't think any other core devs are interested either. Dan: If you have a beef with something in the way change to Python is managed, please say what's bothering you. There's likely more reason to the madness than you think. Requesting that our volunteer-driven organization switches to an expensive new process seems rather premature, don't you think? -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>

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.

Paul Sokolovsky writes:

Hello,

On Sat, 13 Feb 2021 23:10:59 +0900 "Stephen J. Turnbull" <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:

...

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.

You must be kidding, right? Library Reference is full of underspecification and gaps.

No, I'm not kidding. Did you read what I wrote? I did not write that the Python References are perfect and suitable for automatic validation. I wrote that they are of similar quality to most standards published by the IETF or W3C. They are, in my experience. (And at least the IETF email working groups have a much easier task, since it's mostly restricted to syntax of wire protocols -- most semantics are left up to the receiving agents.) For example, the first attempt at a careful description of how the many agents in the email system interact is RFC 5598 (from 2009), while the current controlling RFC for message format is RFC 5322 (from 2008), and the actual standard is STD 11 = RFC 822 (from 1982!). You think you have problems defining free variables in a code block, the IETF email working groups literally operated for decades without trying to define some important terms! If you want more precise definitions and complete specifications in the Language Reference and Library Reference, put them there yourself, and encourage others to do the same. We'll all thank you. And you can be thankful that you only have to get them past the Steering Council, not the member nations (!) of ISO/IEC Joint Technical Committee 1 / Subcommittee 22 / Working Group 21. :-) Steve

https://awesome-safety-critical.readthedocs.io/en/latest/ https://awesome-safety-critical.readthedocs.io/en/latest/#software-safety-st... What is and is not constant time in Python could be added to structured data elements in (implementations') docstrings. ***** "The Python Language Reference" https://docs.python.org/3/reference/ https://docs.python.org/3/reference/lexical_analysis.html https://docs.python.org/3/reference/datamodel.html https://docs.python.org/3/reference/executionmodel.html [...] Python PEG Grammar: https://docs.python.org/3/reference/grammar.html https://github.com/python/cpython/blob/master/Grammar/python.gram https://github.com/python/cpython/blob/master/Lib/test/test_grammar.py "24. Changing CPython’s Grammar" https://devguide.python.org/grammar/ https://devguide.python.org/appendix/#language-development-in-depth :

Exploring CPython’s Internals Changing CPython’s Grammar Design of CPython’s Compiler Design of CPython’s Garbage Collector Adding to the Stdlib Changing the Python Language Porting Python to a new platform

***** Wikipedia: https://en.wikipedia.org/wiki/ECMAScript Homepage: https://www.ecma-international.org/ecma-262/ Src: https://github.com/tc39/ecma262#ecmascript Spec: https://www.ecma-international.org/ecma-262/ Spec: https://tc39.github.io/ecma262/ Spec: https://tc39.es/ecma262/ : ECMA262 Spec Table of Contents: ```quote Introduction 1 Scope 2 Conformance 3 Normative References 4 Overview 5 Notational Conventions 6 ECMAScript Data Types and Values 7 Abstract Operations 8 Syntax-Directed Operations 9 Executable Code and Execution Contexts 10 Ordinary and Exotic Objects Behaviours 11 ECMAScript Language: Source Code 12 ECMAScript Language: Lexical Grammar 13 ECMAScript Language: Expressions 14 ECMAScript Language: Statements and Declarations 15 ECMAScript Language: Functions and Classes 16 ECMAScript Language: Scripts and Modules 17 Error Handling and Language Extensions 18 ECMAScript Standard Built-in Objects 19 The Global Object 20 Fundamental Objects 21 Numbers and Dates 22 Text Processing 23 Indexed Collections 24 Keyed Collections 25 Structured Data 26 Managing Memory 27 Control Abstraction Objects 28 Reflection 29 Memory Model A Grammar Summary B Additional ECMAScript Features for Web Browsers C The Strict Mode of ECMAScript D Host Layering Points E Corrections and Clarifications in ECMAScript 2015 with Possible Compatibility Impact F Additions and Changes That Introduce Incompatibilities with Prior Editions G Colophon H Bibliography I Copyright & Software License ```quote ... https://en.wikipedia.org/wiki/List_of_ECMAScript_engines https://docs.python.org/3/reference/introduction.html#alternate-implementati... On Sat, Feb 13, 2021 at 1:18 PM Stefano Borini <stefano.borini@gmail.com> wrote:

Not sure about python, but throughout my career I had to work with MISRA C standardisation for critical systems. There is more and more that is handled by python that also needs to go through validation. I wonder if there's value in that?

On Fri, 12 Feb 2021 at 18:40, Dan Stromberg <drsalists@gmail.com> wrote:

...

What would it take to create an ANSI, ECMA and/or ISO standard for

Python?

...

It seems to have really helped C.

It looks like Java isn't standardized, and it's done OK, though perhaps

it was healthier in the past - before Oracle decided API's were ownable.

...

I think standardizing Python might be really good for controlling its

growth and avoiding featuritis.

...

_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/JZYW4JOT...

...

Code of Conduct: http://python.org/psf/codeofconduct/

-- Kind regards,

Stefano Borini _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/NR3UAEPE... Code of Conduct: http://python.org/psf/codeofconduct/