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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4