print statement and multithreading

[Alex Martelli]

"Paul Duffin" <pduffin at hursley.ibm.com> wrote in message
news:39ACE1F4.C1235C15 at hursley.ibm.com...
    [snip]
> > the sources of our application to standard C, and that was
> > when we were actively supporting over a dozen platforms.  The
    [snip]
> At last some quantifiable evidence of how many non standard compilers
> there are. < 10%.

Since you're being pedantic, let me be just as pedantic right
back: this was true in 1993, on a biased sample of platforms
(those platforms for which the market demanded us to supply
versions of our mechanical CAD programs).  It makes no sense
to infer from that anything about the situation, 7 years later,
on a set of platforms meeting totally different criteria.


> > Far from being 'meaningless', the standard number is crucial:
> > it's what get specified in contracts.
>
> True but standards numbers by themselves *are* meaningless *unless*
> you have access to the documents that they refer to which as has been
> indicated is limited to those prepared to pay and spend the time
> reading an understanding it.

I have no access to the (older; 1990) version of the ISO standard,
yet the correct identification of that standard is far from
meaningless to me.  Just as I have no access to the original
version of "War and Peace", because I know absolutely no Russian
and thus cannot understand it at all, yet thanks to the magic of
translation, paraphrasing, etc, I can have some grasp of its
contents (not as deep a potential understanding as somebody whose
command of 19-th Century Russian is perfect, and who's thus able
to grasp "Voina i Mir" more fully, at least in theory; but, quite
enough for _most_ purposes).

> Tim kindly pointed me at http://www-ccs.ucsd.edu/c/ which had a very
> readable explanation, and would be a very useful reference to
> standard C.

It's one useful "paraphrase", just as other texts you've been
sugested (K&R, H&S, &c).  But none of those are *normative*;
the _official standard_ is.


> [snipped simplistic analogy with wrenches which doesn't really
>  work because of the complexity differences between a wrench and
>  a compiler]

You're not considering the huge complexity of the metallurgy
that goes into making a wrench of alloys satisfying the relevant
ISO specs.  And the issues scale up without any quantum jump to
machinery of any complexity whatsoever.

You need not grasp the materials-science complexity to use a
wrench effectively, and not even to _specify_ wrenches; it may
help, but it's not a pre-req.  Similarly, although some grasp
of the complexities of compiler-building and standard-specs
may help, they're not pre-req's for using, or specifying, a
compiler effectively.


> > > The point I am trying to make is that all sorts of questions
> > > arise when you say "CPython source is Standard ANSI C".
> >
> > They don't arise in my mind, and I don't think they arise
> > in the mind of anybody who's not being deliberately
> > non-cooperative about it.
>
> I am being pedantic not "deliberately non-cooperative about it".
>
> All I wanted was the definitive reference to the definition of
> "Standard ANSI C" that was used when modifying the Python source
> and which is available in a form that I can read.
>
> I don't think that is a completely unreasonable thing to ask for
> is it. If http://www-ccs.ucsd.edu/c/ is it then that is fine.

It's not, and it cannot be: it has no normative status.  If the
only *normative* document (the ISO standard for the C language)
is one you "cannot" read (because it costs too much money for
your tastes, because you do not understand the language in which
it's made available, or because your sect forbids you to read
documents published by any organization whose name is a 3-letter
acronym), then, yes, it IS completely unreasonable for you to
ask that any of these issues be changed by the Python developers.


> > > 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
> >
> > I think standard C has huge advantages over the chaotic
> > pre-standard situation.  I'm not alone in this belief; I
> > think you might be near-alone in your contrary one.
>
> Apart from changing K&R function definitions to ANSI function
> definitions and always providing prototypes (neither of which
> significantly reduces complexity of the code) what other
> significant changes / simplifications have been made possible
> because of the move to "Standard C".

I can't speak for the Python sources (I hope Tim will do that!),
but, in more general terms (regarding the sources _I_ was
responsible for, directly or as a consultant, lo those many
years ago), being able to rely on Standard C functionality
removed a lot of "nastinesses" depending on previously admissible
variations within the very murkily defined confines of "C
without ANY standard to guide it".

Just one simple example: the standard defined that returning
0 from main (or passing 0 as exit's argument) is the way a
program signals success, non-zero values are non-success
indicators; and termination functions (previously passed to
atexit) are executed when the program returns from main, or
calls exit, whether this is with a 0 or non-0 argument.

Before the standard, these simple semantics could *not* be
guaranteed.  There being no standard, each compiler and its
accompanying libraries did whatever they wished on the matter.
As a result, we had to develop and maintain our own proprietary
infrastructure to ensure uniformity -- ways to register an
exit-callback, ways to ensure program termination with either
success or non-success indicators.  When we moved to the
standard, we could and did simply retire this, and _many
other_, parts of our "platform portability libraries"...
and, good riddance!

The Standard, of course, does not specify _everything_, so
our 'platform portability libraries' ARE still there -- but
the amount of functionality they have to portably supply to
the rest of our application was substantially reduced by
moving to the Standard.


> significantly better than this in terms of quality and simplicity ?
>
> int x _ANSI_ARGS_((int y, int z));
>
> int x (y)
>    int y, z;
> {
> }
>
> Yes it looks more consistent and may take slightly less time to
> type but it does not add anything else. Or does it ?

It adds compiler validation of declaration/implementation
consistency, ability to receive arguments that are char,
short, float, struct, and program correctness (since, in
this quoted example, despite being in pedantic-mode, you
forgot to list x as one of x's arguments:-).  Just for
starters...


Alex