On 2/12/21 5:19 PM, Guido van Rossum wrote:
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.
Having been through ISO standardization several times, a couple of notes.
The first time doesn't have to be particularly expensive - there's a
route where an established organization can register to submit an
already available standard (and I'd argue the Python language docment is
that). However, once you've had the one free hit, you then have to
follow the ISO standards maintenance and development rules going
forward. And that is comparatively expensive.
Is there value? Every healthy project has a "three pillars" approach,
whether stated as such or not, where there is specification, one or more
implementations, and test. It's just that the right balance of those has
to be determined each time (and often evolves over time, as maturity may
change the equation). The specification can be as formal as being
blessed by and under control of a formal body like ISO (though it's
still edited by practitioners), or as informal as "the comments in the
code". An implementation can drive the process ("reference
implementation", where modulo bugs, the implementation determines the
answer if something turns out to be unclear or wrong in the
specification); or an implementation can be relatively obscure, just
used to show "yes, we can indeed implement this". Similarly, tests can
be at the level of checking the implementation, or it can be as formal
as a test suite that is administered by an accredited testing agency,
and passing it (for a fee) is mandatory to be able to use a trademark.
With all that said: Python has all three of the pillars in place: spec,
main implementation, several other implementations of the language, and
a solid test suite. Would changing the balances of those make anything
better than it is now? I'm not a core dev but I fail to see how.
What's the problem that is not being solved now that could be improved?
Is it the recent fairly rate of change?
Postscript: I once participated in "standardizing" Python on a very
limited basis. The Linux Standard Base included a lightweight
description of Python 2.4, with a reference to that version of the
language spec, and a curated list of standard library modules which had
to be provided. The concept was that the user of any LSB-conforming
system would know it was possible to install "LSB Python" and
applications coded to that would then work in the expected way - the
distributions didn't have to provide that as their main Python, just had
to make that "known" version available. Interesting exercise, but in
the end I'm nearly 100% sure that the exercise added no value to the
Python ecosystem which has done just fine for the nearly 20 years since
that bit of work, which has since faded away into obscurity.
Cheers,
-- mats
_______________________________________________
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/B72LUIDFZVWT23E6WWVMYP7C7K4J6JFS/
Code of Conduct: http://python.org/psf/codeofconduct/
