Python Standardization: Wikipedia entry

[Terry Reedy]

"John Nagle" <nagle at animats.com> wrote in message 
news:479f562c$0$36342$742ec2ed at news.sonic.net...
| 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