[Python-Dev] Towards native fileevents in Python (Was Re: Python multiplexing is too hard)

Mark Hammond mhammond@skippinet.com.au
Tue, 23 May 2000 19:00:54 +1000


> Why use a special message ? MsgWait* does multiplex true Windows Message
> *and* other IPC mechanisms.

But the point was that Python programs need to live inside other GUI
environments, and that these GUI environments provide their own message
loops that we must consider a black box.

So, we can not change the existing message loop to use MsgWait*().  We can
not replace their message loop with one of our own that _does_ do this, as
their message loop is likely to have its own special requirements (eg,
MFC's has idle-time processing, etc)

So I can't see a way out of this bind, other than to come up with a way to
live _in_ a 3rd party, immutable message loop.  My message tried to outline
what would be required, for example, to make Pythonwin use such a Python
driven event loop while still using the MFC message loop.

> The key is that there wouldn't be two separate Python/GUI evloops.
> That's the reason for the (a) condition: be able to awaken a
> multiplexing syscall.

Im not sure that is feasable.  With what I know about MFC, I almost
certainly would not attempt to integrate such a scheme with Pythonwin.  I
obviously can not speak for the other GUI toolkit maintainers.

> I believe the next thing to do is to enumerate which GUI packages
> fullfill the following conditions ((a) updated to (a') to reflect the
> first paragraph of this msg):

That would certainly help.  I believe it is safe to say there are 3 major
GUI environments for Python currently released; Tkinter, wxPython and
Pythonwin.  I know Pythonwin does not qualify.  We both know Tkinter does
not qualify.  I dont know enough about wxPython, but even if it _does_
qualify, the simple fact that Tkinter doesnt would appear to be the
show-stopper...

Dont get me wrong - its a noble goal that I _have_ pondered myself in the
past - but can't see a good solution.

Mark.