print statement and multithreading

[Tony J Ibbs (Tibs)]

After having it explained that the ISO C standard costs money,
"Paul Duffin" <pduffin at hursley.ibm.com> wrote:
> 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 ?

<rant>
Unfortunately, the world is set up so that standards bodies have very
limited sources of revenue with which to do their work (and bear in mind
that
(a) most people *on* standards committees are donating *substantial* amounts
of free time to the work,
(b) their employers are probably putting in money, too, if only in lost
"paid work time", and
(c) the standards body itself has to provide background infrastructure which
isn't cheap).

In the UK, British Standards has essentially two sources of income:

1. Selling standards documents
2. Charging people for the privilege of being on committees

[this last one suck, in my not at all humble opinion, but was introduced by
the last government since "everyone knows what a big advantage it is to
companies to influence a standard". Humph. Not our experience - for many
people being on a standards committee is hard work for the sake of the
community, and you don't even get your name on the standard at the end of
the day]
</rant>

Other standards bodies have similar limited funding - basically, what they
can get for selling their stuff.

Mind you, is it really that different if the language is *not* a standard
and one has to buy something to find out its details? (e.g., Python, Tcl,
Perl (several books!), Pascal (in the early days), Delphi, Visual Basic,
etc.) Admittedly, if buying a book one expects a bit lighter prose (and,
thus, less accuracy).

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

Hmm. It's never been a problem before - I mean, these *are* the definitions
of the language!

In practice, this sort of problem *always* comes up if one is doing
multi-platform work. There are two solutions. The first is to invest in a
good book, such as Harbison & Steele "C: A reference manual", which
addresses both the standard and what the common variations are (I learnt C
from the first edition). The second is to buy a copy of the standard - this
latter *does* require also having someone around who can follow it, and is
often omitted.

Oh, and the third thing is "strive not to pull clever tricks, and read the
resources on the web from people who know what they're talking about on what
not to do".

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

Well, actually I think most professional programmers would heave a sigh of
relief, because it means the thing is more likely to be portable (if one
mandates that one actually, as Tim says, means the *previous* standard -
that's why there are standards on how to cite a 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.

Well, I thought our BDFL had said that this wasn't going to happen (or maybe
it was Tim channelling him) - that's good enough for me.

Sorry - this touched a nerve...

Tibs

--
Tony J Ibbs (Tibs)      http://www.tibsnjoan.co.uk/
Give a pedant an inch and they'll take 25.4mm
(once they've established you're talking a post-1959 inch, of course)
My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.)