[Python-Dev] Towards native fileevents in Python (Was Re: Python multiplexing is too hard)
Mon, 22 May 2000 10:19:21 -0500 (CDT)
From firstname.lastname@example.org Mon May 22 08:45:58 2000
Tcl seems to be your only frame of reference. I think it's too early
to say that borrowing Tcl's design is right for Python. Don't forget
that part of Tcl's design was guided by the desire for backwards
compatibility with Tcl's strong (stronger than Python I find!) Unix
Right. We quite agree. Both of us came
to this looking to learn in the first place
what *is* right for Python.
> Then, for the API exposed to the Python programmer, the Tclly exposed
> one is a starter:
> fileevent $channel readable|writable callback
> vwait breaker_variable
> Explanation for non-Tclers: fileevent hooks the callback, vwait does a
> loop of select(). The callback(s) is(are) called without breaking the
> loop, unless $breaker_variable is set, at which time vwait returns.
Sorry, you've lost me here. Fortunately there's more info at
http://dev.scriptics.com/man/tcl8.3/TclCmd/fileevent.htm. It looks
very complicated, and I'm not sure why you rejected my earlier
suggestion to use threads outright as "too complicated". After
reading that man page, threads seem easy compared to the caution one
has to exert when using non-blocking I/O.
> One note about 'breaker_variable': I'm not sure I like it. I'd prefer
> something based on exceptions. I don't quite understand why it's not
> already this way in Tcl (which has (kindof) first-class exceptions), but
> let's not repeat the mistake: let's suggest that (the equivalent of)
> vwait loops forever, only to be broken out by an exception from within
> one of the callbacks.
Vwait seems to be part of the Tcl event model. Maybe we would need to
think about an event model for Python? On the other hand, Python is
at the mercy of the event model of whatever GUI package it is using --
which could be Tk, or wxWindows, or Gtk, or native Windows, or native
MacOS, or any of a number of other event models.
Perhaps this is an issue that each GUI package available to Python
will have to deal with separately...
--Guido van Rossum (home page: http://www.python.org/~guido/)
There are a lot of issues here. I've got clients
with emergencies that'll keep me busy all week,
and will be able to respond only sporadically.
For now, I want to emphasize that Alex and I both
respect Python as itself; it would simply be alien
to us to do the all-too-common trick of whining,
"Why can't it be like this other language I just
Tcl's event model has been more successful than
any of you probably realize. You deserve to know
Should Python have an event model? I'm not con-
vinced. I want to work with Python threading a
bit more. It could be that it answers all the
needs Python has in this regard. The documentation
Guido found "very complicated" above we think of
as ...--well, I want to conclude by saying I find
this discussion productive, and appreciate your
patience in entertaining it. Daemon construction
is a lot of what I do, and, more broadly, I like to
think about useful OS service abstractions. I'll
be back as soon as I have something to contribute.