print statement and multithreading

[Tim Peters]

[Tim]
>> [ANSI/ISO] rely on income from selling hardcopy.

[Paul Duffin]
> Sounds very daft to me.

Not really.  It takes about a decade to produce an ISO/ANSI language std,
and person-centuries of work.  They need money!  Unsure about ISO, but ANSI
gets about 60% of its revenue from selling stds.

> ...
> While that may be true for people who are used to working with
> standards in there raw form I dount that the majority of people
> developing open source software would immediately think of the
> above when you said "ANSI C".
>
> They are more likely to think of the 2nd Edition of K&R.

You program Tcl, right?  Do you read comp.lang.tcl?  If so, do you think
people who program in C seriously avoid comp.lang.c?  There's no secret
here, and hasn't been for 11 years (the current age of "ANSI C").

I'll repeat the link you skipped over; anyone intending to write portable C
who doesn't know this stuff may as well kill themself before they kill the
project they're contributing to <0.9 wink>:

>> An excellent free overview can be found at:
>>
>>      http://www-ccs.ucsd.edu/c/

> ...
> What proportion of the existing compilers are actually ANSI compliant ?

Don't know and don't care, beyond that the ones *I* use are ANSI compliant.
But all programs have bugs, and compilers are no exception.  Any *vendor*
worth dealing with certainly has people familiar with the std on staff, and,
as their user, when I make a case that "there's a bug" in their compiler, I
base my argument on the std.  This is effective; nothing else is.  Compiler
writers take language stds very seriously (not unlike lawyers take law ...).

> What do you take "compliant" to mean in the above context ?

The full meaning of that word is explicitly defined across the hundreds of
dense pages of requirements in the standard.  It's not a touchy-feely thing,
although on occasion there are points open to debate, usually due to the
fuzziness of English.

> What will happen if a compiler which says that it is ANSI compliant
> is not, either because of a bug, or a feature, will you work around
> the limitation (or accept patches which work around the limitation),
> or will you just accept that it cannot be built with that version ?

Python's policy is to work around it, while simultaneously filing a bug
report with the vendor.

> Are there any parts of the Python code which are affected by the
> "behaviour is implementation defined" areas of the standard ?

Of course, but most are in the area of "quality of implementation", where
Python-- as do all other large C programs --sometimes exceeds the minimum
capacities the standard requires of a conforming *compiler* (note that the
std puts requirements on both programs and compilers).  For example, Python
uses some header files whose basenames exceed 6 characters; ANSI C doesn't
*require* a compiler to be able to deal with header file names that long --
but the only compilers worth even *trying* to use certainly do.  Python has
*far* more trouble with the bazillions of inconsistent extensions to the C
standard in common or semi-common use (thinking mostly of C library
functions here).

> If there are are they going to be removed ?

Heh:  how would you know whether Python did <wink>?