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

[Greg Ewing]

Nick Coghlan wrote:

> The main primitive I personally want out of an async API is a
> task-based equivalent to concurrent.futures.as_completed() [1]. 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
other.

Unfortunately, I suspect that a truly elegant solution to this
problem will require yet another language addition -- something
like

    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).

-- 
Greg