[Python-Dev] Re: Python standardization

2021-02-15 Thread Victor Stinner 
See "A formal specification for the (C)Python virtual machine - Python
Language Summit 2020" by Mark Shannon:
https://pyfound.blogspot.com/2020/04/a-formal-specification-for-cpython.html

Victor

On Fri, Feb 12, 2021 at 7:40 PM 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-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/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/2NHEU5AZS3GHJXYAJPFMS27NY737BSPT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-13 Thread Chris Angelico 
On Sun, Feb 14, 2021 at 7:38 AM Wes Turner  wrote:
>
> https://awesome-safety-critical.readthedocs.io/en/latest/
> https://awesome-safety-critical.readthedocs.io/en/latest/#software-safety-standards
>
> What is and is not constant time in Python could be added to structured data 
> elements in (implementations') docstrings.
>

That debate happened a while ago regarding string subscripting. The
conclusion was that "happens in constant time" is NOT part of the
specification. The Python language stipulates that, when you subscript
a string with an integer, you'll get back a single-character string;
but it's absolutely acceptable for an implementation to do this in
O(n) time under certain circumstances if it chooses.

So you're absolutely correct: it would have to be in the
*implementations'* docstrings. It's not part of the language.

ChrisA
___
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/ERAUSQPWKCHM5IFIBZEXQOT2W2RBGFEN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-13 Thread Wes Turner 
https://awesome-safety-critical.readthedocs.io/en/latest/
https://awesome-safety-critical.readthedocs.io/en/latest/#software-safety-standards

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



On Sat, Feb 13, 2021 at 1:18 PM Stefano Borini 
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  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-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/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> > 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-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/NR3UAEPEUJCWDBQVQW3QN4JYZWZNR2IU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/WBDCMKUYRCBG5V3KFZMNOQ3X3S7SODJH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-13 Thread Stephen J. Turnbull 
Paul Sokolovsky writes:
 > Hello,
 > 
 > On Sat, 13 Feb 2021 23:10:59 +0900
 > "Stephen J. Turnbull"  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
___
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/LPTIXDDMFK6T7SZVLBQ4IPILLMOKY45X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-13 Thread Stefano Borini 
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  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-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/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> 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-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/NR3UAEPEUJCWDBQVQW3QN4JYZWZNR2IU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-13 Thread Mats Wichmann 



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/

[Python-Dev] Re: Python standardization

2021-02-13 Thread Luciano Ramalho 
On Fri, Feb 12, 2021 at 3:36 PM Dan Stromberg  wrote:
> I think standardizing Python might be really good for controlling its growth 
> and avoiding featuritis.

The dynamics of standard committees lead to even more acute cases of
featuritis: "I support your pet feature if you support mine."

Cheers,

Luciano



>
> ___
> 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/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Luciano Ramalho
|  Author of Fluent Python (O'Reilly, 2015)
| http://shop.oreilly.com/product/0636920032519.do
|  Technical Principal at ThoughtWorks
|  Twitter: @ramalhoorg
___
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/VTVPNXP3DUQHWQZOSDZWJEFYRRNBQP7X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-13 Thread Paul Sokolovsky 
Hello,

On Sat, 13 Feb 2021 23:10:59 +0900
"Stephen J. Turnbull"  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. Here's a recent example which I bothered
to report and which was even fixed: https://bugs.python.org/issue42559.
Such reports can be easily closed either, so most people don't even try
to report them after initial experience.

Language Reference is also not exactly clearly and well structured, and
leaves doubts about its completeness. For example, there's a common
complaint (in narrow circles?) that Python's scoping rules are unclear
and confusing. And indeed,
https://docs.python.org/3/reference/executionmodel.html#naming-and-binding
could be improved. I recently made a pass over it to clarify some
things, once sweet day I'll post that as a patch, and let's see what
happens (my bet is that it will be closed as many other patches).

As an example from there:

> If a name is bound in a block, it is a local variable of that block,
> unless declared as nonlocal or global. If a name is bound at the
> module level, it is a global variable. (The variables of the module
> code block are local and global.) If a variable is used in a code
> block but not defined there, it is a free variable.

Based on the above, are global/nonlocal vars free in the code block
they are declared in? It's hard to tell, because there's a soup of
terminology - "bound", "defined"; just "block", "code block", etc. And
description there and information available via the
https://docs.python.org/3/library/symtable.html module sometimes don't
agree (there are bugreports on that too).

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
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/F47V5Q7R2AK7SSPMOFJCZ276D4564PVG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-13 Thread Stephen J. Turnbull 
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] Re: Python standardization

2021-02-13 Thread Antoine Pitrou 
On Fri, 12 Feb 2021 21:54:44 +0300
Ivan Pozdeev via Python-Dev  wrote:
> How a standard by ANSI, ECMA and/or ISO is any better than a standard by the 
> PSF?

The PSF has nothing to do with it.  The Python language is controlled
by the core development team.  I wouldn't be surprised if some members
of that team aren't even members of the PSF, and most of them don't
have any responsability at the PSF.

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

Well, it doesn't have any control in any case.  Which isn't necessarily
a bad thing, depending on your view of the PSF.

Whether or not Python is having a case of featuritis obviously depends
on who you ask the question :-)  I personally would answer yes (at
least since PEP 572, and definitely with the pattern matching PEPs),
while others would certainly answer no.

In the end, note that featuritis is not a lethal disease.  C++ is doing
fine. Python won't die because it has pattern matching (it won't be
flourish because of it, either).

Regards

Antoine.

___
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/VYQ27QN7DS243V6QCEJEQFBMVTJE4QAQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-12 Thread Benjamin Peterson 


On Fri, Feb 12, 2021, at 12: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.

That confuses cause and effect. C was standardized because there sprung up 
hundreds of vaguely compatible implementations—a definite mark of success—not 
the other way around.

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

Hmm? https://docs.oracle.com/javase/specs/jls/se15/html/index.html
___
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/YGEHVIHZAS5NM4OTG6NQCWH5NM4CF4EM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-12 Thread Dan Stromberg 
But this message seems to say "Argue with me!"
___
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/SST7KKKTJAEHU73TMWS7GIIR3GNELZA6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-12 Thread Emily Bowman 
A call for standardization is typically done when multiple competing
de-facto standards competing for space, especially if it's relatively
immature, as a way to bring stakeholders together and reduce fragmentation.
You don't just go through the standards process for its own sake, unless
it's a requirement for some specific kind of government contract or
whatever. C and C++ ended up standardized because they blew up and were
implemented in dozens of often-incompatible ways. Python's had a much more
constrained development process, for better or worse, in which there's
traditionally been very little divergence regarding important language
functionality or standard library support in alternate implementations.
Because the language, not just CPython, is allowed to evolve in every minor
version, as well, standardization would just hamstring that.

There's no reason it couldn't be done if the interest was there, but
there's just no really powerful impetus to actually do it. Python the
language isn't splintering. (2 vs 3 is long past us all, and it's not like
2 evolved in implementations that didn't pick up 3.)

-Em

On Fri, Feb 12, 2021 at 10:35 AM 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-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/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/MVDATOACGGA2HNHLSVG4BBD7T4IBDKOC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-12 Thread Guido van Rossum 
>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?)*

___
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/YDAB2RZAIZFMSDVGHYF3PLPQIWMWMZV2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-12 Thread Chris Angelico 
On Sat, Feb 13, 2021 at 10:42 AM Dan Stromberg  wrote:
>
>
> On Fri, Feb 12, 2021 at 2:26 PM Chris Angelico  wrote:
>>
>> On Sat, Feb 13, 2021 at 6:58 AM Dan Stromberg  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

[Python-Dev] Re: Python standardization

2021-02-12 Thread Dan Stromberg 
On Fri, Feb 12, 2021 at 2:26 PM Chris Angelico  wrote:

> On Sat, Feb 13, 2021 at 6:58 AM Dan Stromberg  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?

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.

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.

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.

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.

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

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.

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.

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.

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.
___
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/COZK5QPWEAAVOAAILD7GKIYMJMORX6NG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-12 Thread Dan Stromberg 
On Fri, Feb 12, 2021 at 2:01 PM 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?
>
It's been a long time since I looked at these, but aren't they more
targeted at people developing in Python than people developing a Python
implementation?  The two have some overlap of course, but they aren't
really the same thing.
___
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/QXIAEFI2T7H32QIY6QNCZZVFULMSX7GL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-12 Thread Paul Bryan 
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?
> 

___
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/KG3AN42M3GEJQ3O4SXSK3AZQ3BPNI42L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-12 Thread Chris Angelico 
On Sat, Feb 13, 2021 at 6:58 AM Dan Stromberg  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
___
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/66VCMSUAM5W2HZSZLYUDV6I63QSSMMOC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-12 Thread Greg Ewing 

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?

--
Greg
___
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/EUYJ6W3TKQNSE6EOBQL4W4F2UJDUIDL6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-12 Thread Dan Stromberg 
That could be good.  :)  And sometimes standards are rubber stamped by
other bodies.

On Fri, Feb 12, 2021 at 12:03 PM Paul Bryan  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 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/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> 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/7WXKZFTLABA7L63LRWVVCLCEHZ5NDGRO/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
___
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/36ZVB2LUBRZOLXT4EJ2YCVUYSJ6L4HPB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-12 Thread Paul Bryan 
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
>  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 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-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/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> > > Code of Conduct: http://python.org/psf/codeofconduct/
> > ___
> > 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-d
> > e...@python.org/message/7WXKZFTLABA7L63LRWVVCLCEHZ5NDGRO/
> > Code of Conduct: http://python.org/psf/codeofconduct/

___
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/64TBHFOMEK7ECWSTHA6PMF7RGUH7S6TQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-12 Thread Dan Stromberg 
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 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/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> 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-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/ZBKXMHWFEIWGP7FZJDZPNPV7TEXANMIV/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/7WXKZFTLABA7L63LRWVVCLCEHZ5NDGRO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-12 Thread Dan Stromberg 
On Fri, Feb 12, 2021 at 10:51 AM Paul Bryan  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-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/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
___
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/NC5RVQ55OENLR3AFB6SDXL5AMHHHA2MD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-12 Thread Ivan Pozdeev via Python-Dev 

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

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

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-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/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
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-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/ZBKXMHWFEIWGP7FZJDZPNPV7TEXANMIV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-12 Thread Paul Bryan 
>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'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.

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-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/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/7PM4C6EW633HF4URYN4JTKS7KTAJEPME/
Code of Conduct: http://python.org/psf/codeofconduct/