print statement and multithreading

[Paul Duffin]

Tim Peters wrote:
> 
> [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.
> 

I understand that they need money in order to do the job and I appreciate
that their job is very important, I am just questioning whether selling
copies of standards is the best way to finance it. Standards should be
available to everyone but charging for them limits the audience and hence
limits the effectiveness. I have no idea how much a digital copy of the
standards cost but I do wonder whether it has limited the take up of the
standard. There are also bound to be all sorts of legal copyright issues
which further complicates their use.

The internet standards (RFCs) on the other hand are freely available and
I am sure this has contributed to the growth of the internet.

> > ...
> > 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 do read comp.lang.tcl and I am a serious C programmer but I don't
read comp.lang.c and comp.lang.c++ (maybe I should)

> 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>:
> 

I am not sure what 'stuff' you are referring to, the comp.lang.c archive,
or "ANSI C".

Code can't really be split into "portable" and "not portable", all you
can really say it is somewhere between "very portable" and 
"not very portable".

> >> 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.

No <wink>, therefore must be serious. That doesn't sound like a very
sound basis for deciding on whether or not to require ANSI compliant
compilers.

> 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.
> 

While that may be true in theory it is not true in practice simply because
there are very few people who really understand all the implications of
the standard and how it affects their code.

The ANSI standard does define what a compliant compiler has to do but is
there any way that I can check whether the compiler I have is compliant ?

Is there a reference implementation, or is there a test suite which I
can run against my compiler to determine whether or not it is compliant ?

One problem with trying to write portable code is that while my compiler
may be compliant in the sense that given ANSI code it works as defined
by the language it can also provide extra functionality which I can
easily use by accident. Is there a compiler out there which is pure
ANSI which I can use to verify that my code does not use any of these
extra pieces of functionality.

> > 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.
> 

Do you have a policy on the size / complexity of the work arounds that
you are prepared to accept ?

Accumulation of work arounds can be a big problem so do you have any
policy on when a work around will be removed, e.g. when a fix is
available, when the fixed version of the compiler is shipped as
standard ? If so then you will probably need a database containing
all the details of the fixes.

Have you considered the effect of this on extension writers who 
will / may have to support two versions of the source code, one
for older Python support and one for newer Python support ?

I think that it is a *very bold* step for Python to require an ANSI
compliant compiler; I know that I for one would appreciate being able
to rely on ANSI behaviour. Maybe you could consider setting up a few 
web pages which describe your experiences; it would be very useful
for Python extension writers who will probably have to do a similar
job and would appreciate any advice that you can give them.