print statement and multithreading

Paul Duffin pduffin at hursley.ibm.com
Fri Aug 25 07:16:10 EDT 2000


Alex Martelli wrote:
> 
> "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 know you are right, I have lots of new ideas on how we can 
fix it 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.
> 
> No doubt -- but the wxWindows'ers, right or wrong, preferred
> to re-architect it differently.
> 

It does seem a shame that we end up duplicating this sort of work
over and over again.

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

When you say that Python will support "The C Standard" you 
need to have an exact definition (URL) of the standard, 
"ANSI C" is not sufficient because otherwise everybody will 
have a different idea of what constitutes "ANSI C". This can 
either be a complete standard (preferable), or just the parts 
that Python uses.

Also, are you going to enforce this by checking when 
configuring Python that the compiler is 'Standard', passing
the correct options to the compiler to make it so if it
doesn't default to it or will you rely on the user 'knowing'
enough to do thinks like
	CC="cc -ansi-magic-blah" ./configure ....

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

Probably not.

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

That is a shame.

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

It certainly is feasible because Tcl provides a very consistent
mechanism, however I don't know how feasible it is for Python.
I would have thought that it would be possible to build on the
file objects to provide a nice cross platform version of the
Async module which handles all file types. This is not a trivial
piece of work however.

If Pythoneers thought that it was worth having a nice cross 
platform abstraction for I/O (Python file objects, Tcl channels)
then it may be useful for us to cooperate. Rip the Tcl channels
out of Tcl, generalise them and then plug them back into Python
and Tcl.

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

They probably have although they may argue that it is not a bug but a
different interpretation of the standard, I can't remember what the
specific problem is. I do think that there are people out there using
old versions without the fix, otherwise why would it be part of 
autoconf ?

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

True.



More information about the Python-list mailing list