print statement and multithreading

[Alex Martelli]

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

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

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?


Alex