print statement and multithreading

[Alex Martelli]

"Paul Duffin" <pduffin at hursley.ibm.com> wrote in message
news:39A551D5.BAEC2D87 at hursley.ibm.com...
    [snip]
> It is a shame that these sort of cross platform problems which affect
> all cross platform programmers are not solved once and for always.

How can things ever be fixed "once and for always"?  There will
always be somebody who believes he has a better idea (and he
may be right, or wrong -- doesn't matter in this context) and
has the gumption & know-how to see it through all the way to
implementation.  And you give a good example yourself...:

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

No doubt -- but the wxWindows'ers, right or wrong, preferred
to re-architect it differently.


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

Try www.ansi.gov, but I don't think the previous C standards
(the early ANSI one, the later very similar ISO one that ANSI
also adopted) are available from there; perhaps 'C99', the
current C standard, might be (the C++ Standard can be had
from there for a few dollars, after all).  The "previous C
standard" is what everybody around knows as "ANSI C",
although "ISO C" or maybe "ANSI/ISO C" seems a better
indication to me.


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

But it doesn't apply to unbuffered I/O (setvbuf)...


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

No, I don't think it does in a cross-platform way.


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

I can hardly speak for 'Python in general', but I'm keen on
event-driven as opposed to multi-threading architecture.  I
have no special need for cross-platform _right now_, but
I've had in the past and no doubt will again have in the future,
so I'd definitely like to help achieve something in this field
if it were feasible.


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

No idea.  (If it's so well-known a bug, why doesn't _Sun_
fix it, btw?)


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

No more so than if the same functionality was exposed by
a platform-specific module, surely.


Alex