On Apr 24, 2005, at 11:57 PM, Phillip J. Eby wrote: > At 11:39 PM 4/24/05 -0400, Bob Ippolito wrote: > >> On Apr 24, 2005, at 11:32 PM, Phillip J. Eby wrote: >> >>> At 04:57 PM 4/24/05 -0700, Guido van Rossum wrote: >>>> So a block could return a value to the generator using a return >>>> statement; the generator can catch this by catching ReturnFlow. >>>> (Syntactic sugar could be "VAR = yield ..." like in Ruby.) >>> >>> [uncontrolled drooling, followed by much rejoicing] >>> >>> If this were available to generators in general, you could untwist >>> Twisted. I'm basically simulating this sort of exception/value >>> passing in peak.events to do exactly that, except I have to do: >>> >>> yield somethingBlocking(); result=events.resume() >>> >>> where events.resume() magically receives a value or exception from >>> outside the generator and either returns or raises it. If >>> next()-with-argument and next_ex() are available normally on >>> generators, this would allow you to simulate co-routines without the >>> events.resume() magic; the above would simply read: >>> >>> result = yield somethingBlocking() >>> >>> The rest of the peak.events coroutine simulation would remain around >>> to manage the generator stack and scheduling, but the syntax would >>> be cleaner and the operation of it entirely unmagical. >> >> Only if "result = yield somethingBlocking()" could also raise an >> exception. > > Read Guido's post again; he proposed that passing a result would occur > by raising a ReturnFlow exception! In other words, it's the result > passing that's the exceptional exception, while returning an exception > is unexceptional. :) Oh, right. Too much cold medicine tonight I guess :) You're right, of course. This facility would be VERY nice to ab^Wuse when writing any event driven software.. not just Twisted. -bob
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