On Mon, Oct 15, 2012 at 10:50 AM, Nick Coghlan ncoghlan@gmail.com wrote:
On Tue, Oct 16, 2012 at 12:16 AM, Calvin Spealman ironfroggy@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@gmail.com | Brisbane, Australia