print statement and multithreading

[Paul Duffin]

Alex Martelli wrote:
> 
> "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 *.
> 
[snip description of a 'completely broken' system]

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

Oops, yes strptime was the one I was thinking about. Tcl's solution
was to write its own date scanning routines. This took a significant
amount of effort but results in a much more cross platform solution.
It is a shame that these sort of cross platform problems which affect
all cross platform programmers are not solved once and for always.

I just had a look at wxWindows which apart from the GUI stuff has
threads, mutexes, sockets. A lot of this stuff has already been
done quite neatly in the ACE toolkits.

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

What is the (previous) C standard, do you have a URL ?

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

That is the point I was trying to make.

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

Agreed.

> > 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 don't really know much about this as I try not to use FILE *
stuff as it doesn't fit in with "select" very well. Tcl doesn't
use FILE * because event driven I/O and hence "select" is very
important to it. Instead it has a "channel" abstraction which
sits on top of file descriptors on UNIX and the various types
of Windows handles and whatever the Mac provides. This provides 
a very consistent I/O interface. 

Python on the other hand has file objects which support a
specific interface (open / close / read / write) which is also
a very powerful mechanism but the integration of file objects
with select is missing. I thought that the Async module fixed
that but apparently it doesn't.

Note: As you probably know by now event driven I/O is very 
      important to me, hence my focus on it. If it is not that
      important to you or to Python in general then ignore this.

What about fixing bugs in the standard C libraries ? Does
Python detect and fix the Sun strtod bug ?

> 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 are that it is quick and easy and it provides 
access to the maximum functionality at minimum cost.

The disadvantages are obvious.