print statement and multithreading

[Paul Duffin]

Alex Martelli wrote:
> 
> "Paul Duffin" <pduffin at hursley.ibm.com> wrote in message
> news:39A3A280.62DB98C4 at hursley.ibm.com...
> > Alex Martelli wrote:
>     [snip]
> > > When you open a file, you can specify a third argument of 0 (buffer
> > > size) to get it unbuffered (but this is documented to work only on
> > > systems which have setvbuf in the underlying C library -- which,
> > > fortunately, should include all ISO-standard C compilers, I think).
> >
> > How can you tell from Python whether it is supported or not ?
> > What is the alternative for those cases where it is not supported ?
> > Why doesn't Python emulate this on those systems which don't support
> setvbuf ?
> 
> Sorry, no real idea about any of these.  I suspect the answer is
> that, if your system doesn't LET you do unbuffered I/O, then it
> doesn't, and there's nothing Python can do about it; if it does,
> surely it will expose this through the C ISO-Standard (many call
> it the C ANSI-standard, for historical reasons) setvbuf function.
> 

If it doesn't provide unbuffered I/O then Python could build something
on top of the native file handles rather than FILE *.

> What specific platforms do you have in mind, that do not ("yet"?)
> have ISO-compliant C compilers in the year 2000...?  I.e., that
> DO allow some way to implement unbuffered I/O, but not setvbuf?

I don't know any in particular, I was just wondering what the policy
would be if you encountered one. The standard Python policy seems to
be to provide a low level interface to the existing functionality,
if it is not there then you can't use it. e.g. strftime.

This contrasts with the Tcl policy of *trying* to provide the
same functionality on all platforms as long as it is reasonable
to do so. Both have their advantages and disadvantages.

> Doesn't gcc, lcc, or other free standard-compliant C compiler
> run on said platform, even if the C compiler 'bundled' with the
> machine is not standard?
> 

Probably.

> Yes, as long as Python keeps supporting pre-standard C compilers,
> it would be nice if a Python program could, at runtime, access
> some configuration-information to let it know about limitations
> of the current platform.  But maybe the real answer is to stop
> this support -- start demanding standard C as the prerequisite
> for a platform to have a Python port (and take full unconditional
> advantage of what the C standard mandates).  It's been almost 12
> years since the standard started getting supported, isn't it?
> 

The trouble with this is that there are still platforms out there
which are running non-ANSI compilers. Installing a new compiler
may not be an option for many reasons. I have no idea how many
people this will affect so it may not be a problem.

Tcl uses K&R style definitions and can use ANSI style declarations
if the compiled supports it and this does make things a little 
more fiddly to code but there is no loss of type checking. I
personally would like to move to ANSI definitions too but don't
know how many people will be adversely affected by this so I will
keep a close eye on the reaction to the ANSI version of Python 
2.0.