[Python-ideas] The async API of the future: yield-from

[Calvin Spealman]

On Mon, Oct 15, 2012 at 10:50 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Tue, Oct 16, 2012 at 12:16 AM, Calvin Spealman <ironfroggy at gmail.com> wrote:
>> I'm still -1 on delegating control to subgenerators with yield-from,
>> versus having the scheduler just deal with them directly.  I think it
>> is far less flexible.
>
> Um, yield from is to generators as calls are to functions...
> delegating to subgenerators, regardless of context, is what it's
> *for*. Without it, the scheduler will have to do quite a bit of extra
> work to reconstruct sane stack traces.

I didn't consider the ease of sane stack traces, that is a good point.
I just see all the problems that seem to be harder to do right with yield-from
and I wish it could be made simpler by just bypassing them for coroutines.
I don't feel they are the same as the original intent of yield-from, but I see
the obvious way they match the need now.

But, I still want to make my case and will put another hypothetical on the
board. A "sane stack trace" only makes sense if we assume that tasks
"call" each other in the same kind of call tree that synchronous code flows
in, and I don't think that is necessarily the case. There are cases when one
task might want to end before tasks it as "called" are complete, and if we use
yield-from this is *impossible* but it is very useful.

An example of this is a task which makes multiple requests, but only needs to
wait for the results from less-than-all of them before returning. It
might still want
the other tasks to complete, even if it won't do anything with the results.

yield-from semantics won't allow a called task to continue, if needed, after the
calling task itself has completed.

Is there another way these semantics could be expressed?

> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia



-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://techblog.ironfroggy.com/
Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy