[Python-Dev] Towards native fileevents in Python (Was Re: Python multiplexing is too hard)
Tue, 23 May 2000 12:16:42 +0200
Mark Hammond wrote:
> > I'd really like to challenge that 'almost'...
> Sure - but the problem is simply that MFC has a non-standard message - so
> it _must_ be like I described in my message - and you will agree that
> sounds messy.
> If such a set of multiplexing primitives took off, and people found them
> useful, and started complaining they dont work in Pythonwin, then I will
> surely look at it again. Its too much work and too intrusive for a
> proof-of-concept effort.
> > I understand. Maybe I underestimated some of the difficulties. However,
> > I'd still like to separate what can be separated. The unfriendliness to
> > Python debuggers is sad news to me, but is not strictly related to the
> > problem of heterogeneous multiplexing: if I were to design a debugger
> > from scratch for a random language, I believe I'd arrange for the IPC
> > channel used to be more transparent. IOW, the very fact of using the
> > message queue for the debugging IPC *is* the culprit ! In unix, the
> > ptrace() or /proc interfaces have never walked on the toes of any
> > package, GUI or not...
> The unfriendliness is purely related to Pythonwin, and not the general
> Python debugger. I agree 100% that an RPC type mechanism is far better for
> a debugger. It was just an anecdote to show how fickle these message loops
> can be (and therefore the complex requirements they have).
Okay, so maybe it's time to summarize what we agreed on:
(1) 'tearing open' the main loop of a GUI package is tricky in the
(2) perusing undefined WM_* messages requires care...
(3) on the other hand, all other IPC channels are multiplexable. Even
for the worst case (pipes on Windows) at least 1 (1.5?) method has been
The temporary conclusion as far as I understand, is that nobody in the
Python community has the spare time and energy to tackle (1), that (2)
is tricky due to an unfortunate choice in the implementation of some
debuggers, and that the seemingly appealing unification outlined by (3)
is not enough of a motivation...
Under these conditions, clearly the only option is to put the blackbox
GUI loop inside a separate thread and arrange for it to use a
well-chosen IPC channel to awaken (something like) the Watcher.go()
proposed by Ka-Ping Yee.
Now there's still the issue of actually making select.select()
Any takers ?