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