print statement and multithreading

[Alex Martelli]

"Paul Duffin" <pduffin at hursley.ibm.com> wrote in message
news:39A68EE9.21148649 at hursley.ibm.com...
    [snip]
> > 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.

They've been going at it for a long time, though, and their
standards are widely implemented and used in specifications;
on what time-frame do you believe their 'short-sightedness'
will display itself?  Centuries?  Because surely it hasn't
shown up in mere decades.


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

Are there?  I find far more implementations of, say, Scheme,
that are at variance on some minor points with the (freely
available) R5R, than I've met C compilers at variance with
the ISO standard.  Oh, I don't have a compliance suite for
either, to be sure, but many years ago we decided to upgrade
the sources of our application to standard C, and that was
when we were actively supporting over a dozen platforms.  The
only "side effect" I recall was on some braindead SCO platform,
where the SCO-supplied compiler ("Green Hills" branded, if I
recall correctly) was seriously broken; switching to gcc made
all peace and light again.


> 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

I'm not going to be the one documenting this (and if I were, be
assured I would *NOT* call it 'ANSI' C, but rather *ISO* C).
Far from being 'meaningless', the standard number is crucial:
it's what get specified in contracts.

> an individual do when I want to ensure that my Python extension
> (not that I have one ;-)) is "Standard ANSI C".

You presumably rely on your compiler supplier.

What do you as an individual do, when you want to ensure that
your wrench is in fact a metric wrench by ISO standard so-and-so,
since IKEA (or whomever else you bought your to-be-self-assembled
furniture from) requires such a wrench to assemble it?  Answer:
you rely on your wrench supplier.  You *definitely* don't want
to study the ISO standards on mechanical engineering, and set up
your own conformance-testing shop -- a *very* costly endeavour,
and the price of the standard is of course the least of it.  And
conformance-testing of software as complex as a compiler is not
any cheaper...


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

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.


> Answering those questions will take some effort, and the
> reworking of the source will take a massive effort and for

I think the reworking is complete, so the correct tense
is the past, not the future.

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

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

In practice, this will not change: Python will not run a
compliance-suite and refuse to continue building if that
blows up.  So, if some compiler is not ANSI standard, due
to a bug that makes it erroneously blow up if over than
17 unary pluses are applied, the Python build process will
not notice, nor particularly care.

But if the compiler pukes on
    int x(int y) {
        return 23;
    }
because it's never heard of function prototypes, I seriously
doubt the Python team will now make any effort whatsoever
to build under *that* compiler.  And THIS I see as progress.


Alex