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

[Cameron Laird]

	From guido@cj20424-a.reston1.va.home.com  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
	background.
Right.  We quite agree.  Both of us came
to this looking to learn in the first place
what *is* right for Python.
			.
		[various points]
			.
			.
	> 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
left?"

Tcl's event model has been more successful than
any of you probably realize.  You deserve to know
that.

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.