[Python-ideas] Revised revised revised PEP on yield-from

[Adam Olsen]

On Tue, Feb 17, 2009 at 12:47 PM, Guido van Rossum <guido at python.org> wrote:
> My question was in the context of lightweight threads and your
> proposal for the value returned by "yield from". I believe I now
> understand what you are trying to do, but the way to think about it in
> this case seems very different than when you're refactoring
> generators. IIUC there will be some kind of "scheduler" that manages a
> number of lightweight threads, each represented by a suspended stack
> of generators, and a number of blocking resources like sockets or
> mutexes. The scheduler knows what resource each thread is waiting for
> (could also be ready to run or sleeping until a specific time) and
> when the resource is ready it resumes the generator passing along
> whatever value is required using .send(). E.g. on input, it could read
> the data from the socket, or it could just pass a flag indicating that
> the resource is ready and let the generator make the actual recv()
> call. When a generator wants to access a resource, it uses "yield"
> (not "yield from"!) to send a description of the resource needed to
> the scheduler. When a generator wants to call another function that
> might block, the other function must be written as a generator too,
> and it is called using "yield from". The other function uses "yield"
> to access blocking resources, and "return" to return a value to its
> "caller" (really the generator that used "yield from").

If a scheduler is used it can treat a chained function as just another
resource, either because it has a decorator or simply by default.  I
can't see any need for new syntax.

Overloading return has more merit.  The typical approach today would
be "yield Return(val)" or "raise Return(val)".  However, I'm quite
bothered by the risk of silently swallowing the return argument when
not using a scheduler.


-- 
Adam Olsen, aka Rhamphoryncus