print statement and multithreading

[Paul Duffin]

Alex Martelli wrote:
> 
> "Paul Duffin" <pduffin at hursley.ibm.com> wrote in message
> news:39A6557A.890B7541 at hursley.ibm.com...
>     [snip]
> > When you say that Python will support "The C Standard" you
> > need to have an exact definition (URL) of the standard,
> > "ANSI C" is not sufficient because otherwise everybody will
> 
> URL?!  The International Standards Institute does not
> recognize URL's as valid (normative) concept, I believe.
> An ISO standard is defined by its ISO code and date, not
> by the content of any URL whatsoever.
> 
> "ISO/IEC 9899:1990" is as close as it gets.  The previous
> (ANSI) standard was ANS X3.159-1989, but it was replaced
> by the ISO standard, world-wide, including the United States.
> 
> > have a different idea of what constitutes "ANSI C". This can
> 
> The Standard is fully defined by the above-mentioned documents
> (obviously as amended by the ISO working committees: currently,
> Technical Corrigendum 1 [1994] and Normative Addendum 1 [?date?],
> at least, are law [part of the current definition of ISO 9899,
> and implicitly *and normatively* referenced when that standard
> is specified).
> 
> > either be a complete standard (preferable), or just the parts
> > that Python uses.
> 
> I'm not sure about what you have in mind, but, in case it's
> that, you cannot just publish copies of an ISO Standard: ISO
> retains copyright, and you need to license it from them (such
> licensing fees are used by ISO as a revenue source).
> 

This is so STUPID and short sighted. Surely the whole point of
a standard is that it is everywhere and charging people for
reading it will surely negatively affect the spread of the 
standard. Could this possibly be why there are so many 
non-standard compilers around ?

> I understand it would be different were it strictly a United
> States matter (governmental bodies cannot, by law, own any
> copyright in the US, isn't it so?), but it isn't.
> 

So how do you propose to explain to people what exactly is meant
when Python says that it is "Standard ANSI C" ? The number is
meaningless, you can't freely read the standard, so what do I as
an individual do when I want to ensure that my Python extension
(not that I have one ;-)) is "Standard ANSI C".

> > Also, are you going to enforce this by checking when
> > configuring Python that the compiler is 'Standard', passing
> > the correct options to the compiler to make it so if it> > doesn't default to it or will you rely on the user 'knowing'
> > enough to do thinks like
> > CC="cc -ansi-magic-blah" ./configure ....
> 
> At this point I'm not sure I understand what you mean by
> "you" in this context.  _I_, as an individual, am most likely
> not going to either enforce, or fail to enforce, anything
> whatsoever.  As for "checking", there are no conformance
> suites officially blessed by ISO (that I know of), and I do
> not understand what, pragmatically, that would add.
> 
> A configuration/setup file normally suggests/defaults-to
> certain switches/options for whateve compiler targets, of
> course; e.g., "-lm" is a popular option to ensure the math
> library gets included at link-time.  On a supported platform,
> those switches are part of the way the build is pre-configured;
> on an unknown platform, determining the appropriate switches
> is part of the porting process.  You seem to be implying that
> there is something deeply different from doing this for the
> purpose of "ensuring ISO 9899 is supported at some level"
> rather than the purpose of "ensuring the math libraries are
> included in the link step" -- or, indeed, finding out WHAT
> the name of the C compiler *IS* on some unknown platform
> (surely you don't believe it's "cc" everywhere, right...?-).
> 
> So, what point[s], exactly, are you trying to make, or else
> to ascertain...?
> 

The point I am trying to make is that all sorts of questions
arise when you say "CPython source is Standard ANSI C". 

Answering those questions will take some effort, and the
reworking of the source will take a massive effort and for 
what benefit ? I don't think that you will significantly 
reduce the complexity of the code, or improve it in terms 
of readability because there will always be one compiler 
which isn't quite ANSI due to a bug, or a different 
interpretation of the standard. So the code / configure will
be tweaked to make it work and the same will be done for the
next one, ... before you know it you are back to square one.

As an example just recently someone reported a bug in I think
a quite new version of the HP compiler which meant that "\x12"
sequences weren't handled properly so along came a little patch
to the Tcl core.....

Currently the compilers you support are exactly those compilers
which can compile Python as is which may include some conditional
code as determined by autoconf/configure.