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. :)
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