print statement and multithreading

[Alex Martelli]

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

If a system has a concept of 'native file handles', _and_ some way
to let a C program access them, but chooses to hide that functionality
from the normal <stdio.h> approach of C (forcing it to be buffered
instead), well, what can I say -- I don't see it as Python's job to
try and mend such a peculiarly broken system (such a peculiarly
broken *hypothetical* system, since neither of us can think of any
real, actual example).

Suppose the C compiler didn't have a multiplication operator '*'
(as the C standard requires it to), but the system did let C programs
perform multiplications through calls to the magic API SKWJWMult().
Do you think the developers of the Python interpreter should devote
time and energy to letting Python run on such a peculiarly broken
hypothetical system?  I *definitely* think they have more productive
ways to spend their time, than working around such hypothetical oddities.


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

I think there is a world of difference between functions that
the C standard specifies, such as strftime, and the case you
probably were thinking about, which is strptime (a non-standard
extension, that is offered by some systems/C Compilers, not all).

We've heard that Python 2.0 will (at last) rely on the (previous)
C standard (up to 1.6, it didn't, not fully at least; it still
tried to work at _some_ level even on ancient, pre-standard C
compilers).  I salute this as a Very Good Thing.

Exposing *in the standard Python libraries* functionality that
is not standard, and is going to be present on some platforms
but not on others, is, on the other hand, an extremely peculiar
position, I think.  Surely, that's what platform-specific modules
are for: exposing what's there to expose on some platforms but
not on others.  Letting, e.g., strptime be usable (from a non
platform-specific module) on some platforms but not on others
exposes programmers to serious portability gotchas.


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

We may disagree on the meaning of 'reasonable'.  I think it's
not reasonable, today, to emulate standard-required features on
platforms that are not standard-compliant 10+ years after the
standard was approved.  The buffered-IO being discussed is a
case in point, isn't it?

I also think it's just about advantage-free to have standard,
non-platform-specific Python modules expose different sets of
functions depending on the platform.  The 'advantages vs
disadvantages' issue may apply to distributing platform specific
modules *as part of the standard Python distribution* rather
than in separate packages; I find it, at least, pretty confusing
(particularly in the docs -- why should the Windows-specific
"ActivePython 1.6 Documentation" .chm file include a Macintosh
specific manual, SGI-specific modules' docs, etc, but not most
of the Win32-specific stuff...?  but having such modules as
sunau.py and sunaudio.py in the Lib directory is also maybe
not optimally clear).


Alex