Python Standardization: Wikipedia entry

[Paddy]

I would value the opinion of fellow Pythoneers who have also
contributed to Wikipedia, on the issue of "Is Python Standardized".
Specifically in the context of this table:
http://en.wikipedia.org/wiki/Comparison_of_programming_languages#General_comparison
(Comparison of programming languages)
And this entry in the talk page
http://en.wikipedia.org/wiki/Talk:Comparison_of_programming_languages#Standardized_Python.3F
(Talk:Comparison of programming languages#Standardized Python?)

- Thanks.

 

[ajaksu]

I would value the opinion of fellow Pythoneers who have also
contributed to Wikipedia, on the issue of "Is Python Standardized".
Specifically in the context of this table:
http://en.wikipedia.org/wiki/Comparison_of_programming_languages#Gene...
(Comparison of programming languages)
And this entry in the talk page
http://en.wikipedia.org/wiki/Talk:Comparison_of_programming_languages...
(Talk:Comparison of programming languages#Standardized Python?)

- Thanks.

Hmmm. Seems to me that "Is X Standardized" in the given context means
having a formal, published standard issued by some Standards
organization. While you can discuss the meaning of some so-called
standards (like W3C's 'recommendations', RFCs, etc.), Python, IMHO,
doesn't fit the label. There is no "Standard" to reference that is
implementation, documentation and core-dev's opinion independent to a
reasonable degree.

I guess MilesAgain gives the best arguments regarding this issue.

Not-that-my-opinion-should-have-any-weight-ly y'rs
Daniel

 

[Paddy]

Hmmm. Seems to me that "Is X Standardized" in the given context means
having a formal, published standard issued by some Standards
organization. While you can discuss the meaning of some so-called
standards (like W3C's 'recommendations', RFCs, etc.), Python, IMHO,
doesn't fit the label. There is no "Standard" to reference that is
implementation, documentation and core-dev's opinion independent to a
reasonable degree.

I guess MilesAgain gives the best arguments regarding this issue.

Not-that-my-opinion-should-have-any-weight-ly y'rs
Daniel

Thanks Daniel. I am very close to the issue and would like to step
back and c.l.p'ers opinion.

 

[Roy Smith]

Hmmm. Seems to me that "Is X Standardized" in the given context means
having a formal, published standard issued by some Standards
organization.

That's exactly what it means. For example, if I'm buying a C++ compiler, I
can specify in the contract, "Must comply with ISO 14882", and everybody
will know what I'm talking about.

On the other side of the fence, if I'm a free-lance C++ developer, I can
specify to my customers that the code I write will work properly when
compiled with a compiler that meets ISO 14882. Whether such a compiler
actually exists, is besides the point

Python has no such standard. Sure, there's the stuff on docs.python.org,
but it's kind of hard to write a contract which says, "Must comply with the
stuff on docs.python.org", and have it be meaningful in a legal sense.

So, I think the "No" in the "Standardized?" column for python is exactly
right. That's not to say you can't have something good which isn't
standardized. Sometimes standards committees even go off into left field
and field break stuff in the process of standardizing it. Some things have
so many different standards (i.e. the pletora of unix standards), it's
almost worthless to say it's standardized. But, as it stands, the
Wikipedia article is correct.

 

[Russ P.]

That's exactly what it means. For example, if I'm buying a C++ compiler, I
can specify in the contract, "Must comply with ISO 14882", and everybody
will know what I'm talking about.

On the other side of the fence, if I'm a free-lance C++ developer, I can
specify to my customers that the code I write will work properly when
compiled with a compiler that meets ISO 14882. Whether such a compiler
actually exists, is besides the point

Python has no such standard. Sure, there's the stuff on docs.python.org,
but it's kind of hard to write a contract which says, "Must comply with the
stuff on docs.python.org", and have it be meaningful in a legal sense.

So, I think the "No" in the "Standardized?" column for python is exactly
right. That's not to say you can't have something good which isn't
standardized. Sometimes standards committees even go off into left field
and field break stuff in the process of standardizing it. Some things have
so many different standards (i.e. the pletora of unix standards), it's
almost worthless to say it's standardized. But, as it stands, the
Wikipedia article is correct.

I agree. As far as I know, Python is not formally
"standardized" by any recognized standards
authority such as ANSI or ISO. (If it were, it
wouldn't have a "BDFL.")

For most domains in which Python is used, that is
not an issue, but for some potential uses it could
be (e.g., safety-critical).

FWIW, the "most" standardized language is probably
Ada. Not only does it have a formal written
standard, but I believe it also has a formal
suite of tests that a standard Ada compiler is
required to pass. [For some reason, Ada does not
get the respect or the attention it deserves, but
that's another topic.]

 

[Paddy]

<[email protected]>,

That's exactly what it means. For example, if I'm buying a C++ compiler, I
can specify in the contract, "Must comply with ISO 14882", and everybody
will know what I'm talking about.

On the other side of the fence, if I'm a free-lance C++ developer, I can
specify to my customers that the code I write will work properly when
compiled with a compiler that meets ISO 14882. Whether such a compiler
actually exists, is besides the point

Python has no such standard. Sure, there's the stuff on docs.python.org,
but it's kind of hard to write a contract which says, "Must comply with the
stuff on docs.python.org", and have it be meaningful in a legal sense.

So, I think the "No" in the "Standardized?" column for python is exactly
right. That's not to say you can't have something good which isn't
standardized. Sometimes standards committees even go off into left field
and field break stuff in the process of standardizing it. Some things have
so many different standards (i.e. the pletora of unix standards), it's
almost worthless to say it's standardized. But, as it stands, the
Wikipedia article is correct.

I agree. As far as I know, Python is not formally
"standardized" by any recognized standards
authority such as ANSI or ISO. (If it were, it
wouldn't have a "BDFL.")

For most domains in which Python is used, that is
not an issue, but for some potential uses it could
be (e.g., safety-critical).

FWIW, the "most" standardized language is probably
Ada. Not only does it have a formal written
standard, but I believe it also has a formal
suite of tests that a standard Ada compiler is
required to pass. [For some reason, Ada does not
get the respect or the attention it deserves, but
that's another topic.]

Thanks Roy, Russ. I agree that Python is not standardized the way
other languages are.
But still, I look at the table, read the article linked as the column
header, and can see that their is discrepancy.
The column header links to the article on standardization:
http://en.wikipedia.org/wiki/Standardization
Which has a definition of standardization which is very different from
what you may cite.

I read the column headings article and just can't help feeling that
Python conforms to *that* definition.

- Paddy.

 

[Paul Boddie]

Hmmm. Seems to me that "Is X Standardized" in the given context means
having a formal, published standard issued by some Standards
organization. While you can discuss the meaning of some so-called
standards (like W3C's 'recommendations', RFCs, etc.), Python, IMHO,
doesn't fit the label. There is no "Standard" to reference that is
implementation, documentation and core-dev's opinion independent to a
reasonable degree.

I guess MilesAgain gives the best arguments regarding this issue.

Agreed. The supposed definition of Python is decided by the developers
of CPython, which is why every other implementation has to chase
behind that group making changes as the language definition shifts.
You could argue that Java is in a similar situation: a controlling
body with their own implementations, albeit with a process for
suggesting changes and arguably more complete documentation. Looking
at the table of languages, we see that Java is indeed categorised as
not having a standard.

Of course, one could contend that languages like C# aren't really
standardised either, since everyone knows that ECMA standardisation is
just a convenient rubber-stamping process, as we have seen with the
adoption of "Office Open XML" (OOXML) as a standard by ECMA, whilst
the ISO standardisation attempt for OOXML was sunk (despite Microsoft
ballot-stuffing) due to glaring flaws in that so-called standard.

As I probably pointed out before, people have advocated a standard for
Python, such as a presenter at EuroPython 2006 who had been alarmed
that features such as lambda which his team used extensively were at
one point scheduled for removal from the language. Unfortunately,
there hasn't been significant scope for differentiation between
implementations of Python, so one could argue that demand for a
standard hasn't yet reached a critical level, but I imagine that some
kind of independent documentation of what Python (or a subset of
Python) is may eventually emerge in some form or other.

Paul

 

[Terry Reedy]

|I would value the opinion of fellow Pythoneers who have also
| contributed to Wikipedia, on the issue of "Is Python Standardized".

Depends entirely on the operative meaning of standardized. Formal
standards body? Obviously no.

Specified in a standard-setting document? Yes. In fact, in someways,
Python is better standardized that C, for instance, in that the Python
standard usefully standardizes some things that the C standard leaved
unstandardized as 'implementation defined'.

Example 1. Order of evaluation of function arguments. Python: left to
right. C: undefined (and unstandardized), I believe.

Example 2: Strings for Infinity and Not-A-Number. Python: will standardize
in 2.6 to hide the variation in C implementations (or is Microsoft just
non-compliant here?).

 

[Roy Smith]

|I would value the opinion of fellow Pythoneers who have also
| contributed to Wikipedia, on the issue of "Is Python Standardized".

Depends entirely on the operative meaning of standardized. Formal
standards body? Obviously no.

Specified in a standard-setting document? Yes. In fact, in someways,
Python is better standardized that C, for instance, in that the Python
standard usefully standardizes some things that the C standard leaved
unstandardized as 'implementation defined'.

Example 1. Order of evaluation of function arguments. Python: left to
right. C: undefined (and unstandardized), I believe.

Example 2: Strings for Infinity and Not-A-Number. Python: will standardize
in 2.6 to hide the variation in C implementations (or is Microsoft just
non-compliant here?).

But, surely Python has plenty of "implementation defined" aspects.
Especially in the libraries. Especially those parts of the libraries which
are thin layers on top of operating system services (os and socket come to
mind as two highly variable areas).

 

[Terry Reedy]

| But, surely Python has plenty of "implementation defined" aspects.
| Especially in the libraries.

I personally do not consider the libraries as part of the language (as
opposed to the distribution) and was not referring to them. The semantics
of the syntax is pretty tightly defined. The main exception is floating
point, which is a nuisance. Which is why one implementation aspect thereof
is being standardized in the next version.

| Especially those parts of the libraries which
| are thin layers on top of operating system services (os and socket come
to
| mind as two highly variable areas).

I am sure that sockets are not part of the C89 standard. Hence the high
variability. (I don't know about the newer C standard). I would expect
that socket.py makes the variability no worse and presume that it masks at
least a bit of it. Ditto for some os services.

tjr

 

[Roy Smith]

| But, surely Python has plenty of "implementation defined" aspects.
| Especially in the libraries.

I personally do not consider the libraries as part of the language (as
opposed to the distribution) and was not referring to them.

I realize that there is a difference between the core language and the
libraries, but Python depends on the libraries more than a lot of other
languages do. They are the "batteries included" part.

Indeed, there is a lot of stuff in the "Python Library Reference" which in
most languages would be considered part of the core. The description of
boolean operations (and, or, not), for example. String, sequence, and
dictionary methods. Where do you draw the line and say, "The core language
ends here; the rest is just libraries"?

 

[John Nagle]

I would value the opinion of fellow Pythoneers who have also
contributed to Wikipedia, on the issue of "Is Python Standardized".
Specifically in the context of this table:
http://en.wikipedia.org/wiki/Comparison_of_programming_languages#General_comparison
(Comparison of programming languages)
And this entry in the talk page
http://en.wikipedia.org/wiki/Talk:Comparison_of_programming_languages#Standardized_Python.3F
(Talk:Comparison of programming languages#Standardized Python?)

- Thanks.

That's correct. Python is not standardized by any standards body. And no
two implementations are even close to compiling the same language.

A consequence of the lack of standardization is that it discourages
implementations. There are about four implementations of something like
Python (other than CPython), and none of them are close to being usable.
Letting the author of one implementation control the language discourages
other implementations.

Submitting Python 2.5 to ISO/ANSI might be a good idea.

John Nagle

 

[Colin J. Williams]

That's correct. Python is not standardized by any standards body.
And no
two implementations are even close to compiling the same language.

A consequence of the lack of standardization is that it discourages
implementations. There are about four implementations of something like
Python (other than CPython), and none of them are close to being usable.
Letting the author of one implementation control the language discourages
other implementations.

Submitting Python 2.5 to ISO/ANSI might be a good idea.

John Nagle

Better to wait for 3.0?

Colin W.

 

[Terry Reedy]

| And no two implementations are even close to compiling the same language.

That is not what some alternate implementors have claimed. How you done
actual tests to prove them wrong? (And, of course, 'close' would need some
discussion.)

| A consequence of the lack of standardization is that it discourages
implementations.

Evidence? My impression is that there were more implementations of C
before it was standardized than after, or certainly now.

Anyway, as I have already said, I think Python is in someways better
standardized (even if 'unofficially') than C. Another example: in Python,
n >> i == n//(2**i) for integer n and non-negative integer i. C89 gives
the same for non-negative n but the result is 'implementation defined' for
negative n. (Yes, I know at least partially why the committee could not
agree on a standard definition for this case.)

I think one thing being overlooked in implementation counts is that CPython
is in a real sense several implementations: one each for WinNT, Linux, MAC,
OS, Solaris, and so one. They happen to be nearly the same with the diffs
implemented as C #ifdefs.

The reason for this, in turn, is that CPython is open source *and*
welcoming of patches to make all the different versions. So someone
wanting to write a version for system X does not have to start from scratch
but only has to write miminal patches. (Yes, this is helped by C
standardization, as well as CPython being intentionally writen for
portability.)

The proliferation of C implementations in the 80s was at least partly due
to most being proprietary closed source. So there was a lot of duplication
of effort, as well as the sometimes rather useless variations that
stimulated the official standard.

Terry Jan Reedy

 

[John Nagle]

Better to wait for 3.0?

I'd argue for standardizing from 2.5, and viewing 3.x as a possible
future upgrade.

John Nagle

 

[Terry Reedy]

Submitting Python 2.5 to ISO/ANSI might be a good idea.

ANSI does not actually make standards. It make metastandards about how to
make standards (both style and process) and accredites US standard-making
bodies that will follow those metastandards. The processes require
committee meetings and public comment periods -- a few years and some $$$.
There in no guarantee that what would come out of such a process would be
what went in, so 'Standard Python' might easily be a language with no
implementations.

ANSI standards are owned by ANSI or perhaps the accrediting body. In any
case, electronic copies sell for $30. They cannot legally be accessed free
as for the docs at python.org.

 

[Paddy]

ANSI does not actually make standards. It make metastandards about how to
make standards (both style and process) and accredites US standard-making
bodies that will follow those metastandards. The processes require
committee meetings and public comment periods -- a few years and some $$$.
There in no guarantee that what would come out of such a process would be
what went in, so 'Standard Python' might easily be a language with no
implementations.

ANSI standards are owned by ANSI or perhaps the accrediting body. In any
case, electronic copies sell for $30. They cannot legally be accessed free
as for the docs at python.org.

HI Terry,
Is their a standardizing body out their to `legitimise` open source
languages like Python?

- Paddy.

 

[Terry Reedy]

| > ANSI does not actually make standards. It make metastandards about how
to
| > make standards (both style and process) and accredites US
standard-making
| > bodies that will follow those metastandards. The processes require
| > committee meetings and public comment periods -- a few years and some
$$$.
| > There in no guarantee that what would come out of such a process would
be
| > what went in, so 'Standard Python' might easily be a language with no
| > implementations.
| >
| > ANSI standards are owned by ANSI or perhaps the accrediting body. In
any
| > case, electronic copies sell for $30. They cannot legally be accessed
free
| > as for the docs at python.org.
|
| HI Terry,
| Is their a standardizing body out their to `legitimise` open source
| languages like Python?

Not that I know of. There are at least a couple hundred ANSI-accredited
bodies. The application fee to become one is $3000. But some group could
act independently, perhaps with streamlined procedures, including meeting
by email or chat to cut out the large expenses of meetings, for instance.

tjr

 

[Daniel Fetchinson]

Depends entirely on the operative meaning of standardized. Formal

standards body? Obviously no.

Specified in a standard-setting document? Yes. In fact, in someways,
Python is better standardized that C, for instance, in that the Python
standard usefully standardizes some things that the C standard leaved
unstandardized as 'implementation defined'.

Unstandardized and undefined are two different things. If the standard
says "this is implementation defined AKA undefined" is just as clear
and unambiguous as saying "this is defined so and so". Both statement
are equally clear as to determine if a code conforms to the standard
or not. The purpose of a standard is not to define everything but
define clearly certain things and make it equality clear what is not
defined and is left as an implementation detail.

 

[Bruno Desthuilliers]

John Nagle a écrit :
(snip)

Python is not standardized by any standards body.
And no
two implementations are even close to compiling the same language.

A consequence of the lack of standardization is that it discourages
implementations. There are about four implementations of something like
Python (other than CPython),

Given that Python is a relatively "small" language (wrt/ visibility,
compared to say C, Ada, Java etc), I'd say this already makes quite a
lot implementations (how many Perl implementations around ?) - which
contradict your first assertion.

and none of them are close to being usable.

Care to back this claim ?

FWIW, I've only played with stackless so far, and I mean "played" - not
"effectively tried to use on production" - but AFAICT it seems to work
just fine. Jython is a couple versions behind, but I wouldn't count this
as "not close to being usable". Don't know about IronPython (not
interested in this .NET stuff) but I've not seen any complaint about it
so far. So if you have more informations about all these "unusable"
implementations, please share.

Letting the author of one implementation control the language discourages
other implementations.

GvR is not "the author of one implementation" but the author of the
language itself.

Submitting Python 2.5 to ISO/ANSI might be a good idea.

Or a very bad one. Anyway, GvR - as the author - has the final word on
this. You can try to convince him if you want.