[Python-Dev] Python standardization

42 views
Skip to first unread message

Dan Stromberg

unread,
Feb 12, 2021, 1:34:31 PM2/12/21
to Python-Dev

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.

Paul Bryan

unread,
Feb 12, 2021, 1:56:22 PM2/12/21
to Dan Stromberg, Python-Dev
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.

Ivan Pozdeev via Python-Dev

unread,
Feb 12, 2021, 2:02:12 PM2/12/21
to pytho...@python.org

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?

-- 
Regards,
Ivan

Dan Stromberg

unread,
Feb 12, 2021, 2:49:29 PM2/12/21
to Paul Bryan, Python-Dev
On Fri, Feb 12, 2021 at 10:51 AM Paul Bryan <pbr...@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.

Dan Stromberg

unread,
Feb 12, 2021, 3:02:23 PM2/12/21
to Ivan Pozdeev, Python-Dev
On Fri, Feb 12, 2021 at 11:02 AM Ivan Pozdeev via Python-Dev <pytho...@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 -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
Code of Conduct: http://python.org/psf/codeofconduct/

-- 
Regards,
Ivan
_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Paul Bryan

unread,
Feb 12, 2021, 3:09:53 PM2/12/21
to Dan Stromberg, Ivan Pozdeev, Python-Dev
What if PSF were to undertake codifying a language specification?

Dan Stromberg

unread,
Feb 12, 2021, 3:17:34 PM2/12/21
to Paul Bryan, Python-Dev

That could be good.  :)  And sometimes standards are rubber stamped by other bodies.

Greg Ewing

unread,
Feb 12, 2021, 4:58:45 PM2/12/21
to pytho...@python.org
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 -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/EUYJ6W3TKQNSE6EOBQL4W4F2UJDUIDL6/

Chris Angelico

unread,
Feb 12, 2021, 5:26:10 PM2/12/21
to Python-Dev
On Sat, Feb 13, 2021 at 6:58 AM Dan Stromberg <drsa...@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
_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/66VCMSUAM5W2HZSZLYUDV6I63QSSMMOC/

Paul Bryan

unread,
Feb 12, 2021, 5:36:30 PM2/12/21
to Greg Ewing, pytho...@python.org
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.

Dan Stromberg

unread,
Feb 12, 2021, 6:01:46 PM2/12/21
to Greg Ewing, Python-Dev
On Fri, Feb 12, 2021 at 2:01 PM Greg Ewing <greg....@canterbury.ac.nz> 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.

Dan Stromberg

unread,
Feb 12, 2021, 6:47:26 PM2/12/21
to Chris Angelico, Python-Dev
On Fri, Feb 12, 2021 at 2:26 PM Chris Angelico <ros...@gmail.com> wrote:
On Sat, Feb 13, 2021 at 6:58 AM Dan Stromberg <drsa...@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?

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.

Chris Angelico

unread,
Feb 12, 2021, 7:13:24 PM2/12/21
to Python-Dev
On Sat, Feb 13, 2021 at 10:42 AM Dan Stromberg <drsa...@gmail.com> wrote:
>
>
> On Fri, Feb 12, 2021 at 2:26 PM Chris Angelico <ros...@gmail.com> wrote:
>>
>> On Sat, Feb 13, 2021 at 6:58 AM Dan Stromberg <drsa...@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
_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/YEFHRRXKPKKKJF6WHOOXLQSJ3UQLHQC6/

Guido van Rossum

unread,
Feb 12, 2021, 7:26:22 PM2/12/21
to Dan Stromberg, Python-Dev
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)

Emily Bowman

unread,
Feb 12, 2021, 7:55:09 PM2/12/21
to Dan Stromberg, Python-Dev
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

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/

Dan Stromberg

unread,
Feb 12, 2021, 8:02:40 PM2/12/21
to Chris Angelico, Python-Dev

But this message seems to say "Argue with me!"

Benjamin Peterson

unread,
Feb 12, 2021, 11:41:50 PM2/12/21
to Dan Stromberg, Python-Dev


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 -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/YGEHVIHZAS5NM4OTG6NQCWH5NM4CF4EM/

Antoine Pitrou

unread,
Feb 13, 2021, 5:46:17 AM2/13/21
to pytho...@python.org
On Fri, 12 Feb 2021 21:54:44 +0300
Ivan Pozdeev via Python-Dev <pytho...@python.org> 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 -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/VYQ27QN7DS243V6QCEJEQFBMVTJE4QAQ/

Stephen J. Turnbull

unread,
Feb 13, 2021, 9:16:00 AM2/13/21
to Chris Angelico, Python-Dev
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 -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/GCFOLVSRUB3KZL37O5EOLFXXGQQKLP5X/

Paul Sokolovsky

unread,
Feb 13, 2021, 10:17:15 AM2/13/21
to Stephen J. Turnbull, Python-Dev
Hello,

On Sat, 13 Feb 2021 23:10:59 +0900
"Stephen J. Turnbull" <turnbull....@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. 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:pmi...@gmail.com
_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/F47V5Q7R2AK7SSPMOFJCZ276D4564PVG/

Luciano Ramalho

unread,
Feb 13, 2021, 11:34:45 AM2/13/21
to Dan Stromberg, Python-Dev
On Fri, Feb 12, 2021 at 3:36 PM Dan Stromberg <drsa...@gmail.com> 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 -- pytho...@python.org
> To unsubscribe send an email to python-d...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at https://mail.python.org/archives/list/pytho...@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 -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/VTVPNXP3DUQHWQZOSDZWJEFYRRNBQP7X/

Mats Wichmann

unread,
Feb 13, 2021, 12:40:26 PM2/13/21
to pytho...@python.org

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 -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/B72LUIDFZVWT23E6WWVMYP7C7K4J6JFS/

Stefano Borini

unread,
Feb 13, 2021, 1:20:57 PM2/13/21
to Dan Stromberg, Python-Dev
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?
> _______________________________________________
> Python-Dev mailing list -- pytho...@python.org
> To unsubscribe send an email to python-d...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> Code of Conduct: http://python.org/psf/codeofconduct/



--
Kind regards,

Stefano Borini
_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/NR3UAEPEUJCWDBQVQW3QN4JYZWZNR2IU/

Stephen J. Turnbull

unread,
Feb 13, 2021, 2:21:05 PM2/13/21
to Paul Sokolovsky, Python-Dev
Paul Sokolovsky writes:
> Hello,
>
> On Sat, 13 Feb 2021 23:10:59 +0900
> "Stephen J. Turnbull" <turnbull....@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
_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/LPTIXDDMFK6T7SZVLBQ4IPILLMOKY45X/

Wes Turner

unread,
Feb 13, 2021, 3:42:09 PM2/13/21
to Stefano Borini, Python-Dev
https://awesome-safety-critical.readthedocs.io/en/latest/

What is and is not constant time in Python could be added to structured data elements in (implementations') docstrings.

*****

"The Python Language Reference"
[...]

Python PEG Grammar:
"24. Changing CPython’s Grammar"


> 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

*****


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



Chris Angelico

unread,
Feb 13, 2021, 3:46:54 PM2/13/21
to Python-Dev
On Sun, Feb 14, 2021 at 7:38 AM Wes Turner <wes.t...@gmail.com> 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 -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/ERAUSQPWKCHM5IFIBZEXQOT2W2RBGFEN/

Victor Stinner

unread,
Feb 15, 2021, 3:00:19 AM2/15/21
to Dan Stromberg, Python-Dev
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 <drsa...@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 -- pytho...@python.org
> To unsubscribe send an email to python-d...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at https://mail.python.org/archives/list/pytho...@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 -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/2NHEU5AZS3GHJXYAJPFMS27NY737BSPT/
Reply all
Reply to author
Forward
0 new messages