Home Original page

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

Greg Ewing greg.ewing at canterbury.ac.nz
Sat Oct 20 07:52:53 CEST 2012 
Devin Jeanpierre wrote:
>>If I wrote a library intended for serious use, the end user
>>probably wouldn't write either of those. Instead he would
>>write something like
>>
>>   yield from block(self.queue)

> What's the benefit of having both "yield" and "yield from" as opposed
> to just "yield"? It seems like an attractive nuisance if "yield" works
> but doesn't let the function have implementation details and wait for
> more than one thing or somesuch.

The documentation would say to use "yield from", and if
someone misreads that and just says "yield" instead, it's
their own fault.

I don't think it's worth the rather large increase in the
complexity of the scheduler implementation that would be
required to make "yield foo()" do the same thing as
"yield from foo()" in all circumstances, just to rescue
people who make this kind of mistake.

It's unfortunate that "yield" and "yield from" look so
similar. This is one way that cofunctions would help, by
making calls to subtasks look very different from yields.

> My understanding is that the only benefit we get here is nicer
> tracebacks. I hope there's more.

You also get a much simpler and much more efficient
scheduler implementation.

-- 
Greg
More information about the Python-ideas mailing list