[Python-ideas] The async API of the future: yield-from
greg.ewing at canterbury.ac.nz
Mon Oct 15 22:14:47 CEST 2012
Nick Coghlan wrote:
> The main primitive I personally want out of an async API is a
> task-based equivalent to concurrent.futures.as_completed() . This
> is what I meant about iteration being a bit of a mess: the way the
> as_completed() works, the suspend/resume channel of the iterator
> protocol is being used to pass completed future objects back to the
> calling iterator. That means that channel *can't* be used to talk
> between the coroutine and the scheduler,
I had to read this a couple of times before I figured out
what you're talking about, but I get it now.
This is an instance of a general problem that was noticed
back when I was discussing my cofunctions idea: using
generator-based coroutines, it's not possible to have a
"suspendable iterator", because that would require "yield"
to have two conflicting meanings: "suspend this coroutine"
on one hand, and "provide a value to my caller" on the
Unfortunately, I suspect that a truly elegant solution to this
problem will require yet another language addition -- something
yield for item in subtask():
which would run a slightly different version of the iterator
protocol in which values to be yield are wrapped somehow
(I haven't figured out all the details yet).
More information about the Python-ideas