print statement and multithreading

[Paul Duffin]

Alex Martelli wrote:
> 
> "Paul Duffin" <pduffin at hursley.ibm.com> wrote in message
> news:39A68EE9.21148649 at hursley.ibm.com...
[snipped emotional reaction]

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

gcc is SOOO useful.

At last some quantifiable evidence of how many non standard compilers
there are. < 10%.

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

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.

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.

> > 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.
> 
[snipped simplistic analogy with wrenches which doesn't really
 work because of the complexity differences between a wrench and
 a compiler]

> conformance-testing of software as complex as a compiler is not
> any cheaper...
> 

True.

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

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.

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

Python source code is reasonable portable anyway so avoids
most of the platform / compiler dependent nastinesses anyway.

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

Why is

	int x (int y, int z);

	int x (int y, int z)
	{
	}

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 ?