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

[Greg Ewing]

Guido van Rossum wrote:
> But, as Christian Tismer wrote, we need to have some kind of idea of
> what the primitives are that we want to support.

Well, I was just responding to your asking what the yield-from
equivalent would be to the corresponding thing using Futures.
I assumed from the fact that you asked that it was something
Futures-using people like to do a lot, so it would be worth
putting into a library.

There may be other ways to approach it, though. Suppose we
had a primitive that just waits for a single task to finish
and returns its value. Then we could do this:

    def par(*tasks):
      for task in tasks:
         scheduler.schedule(task)
      return [yield from scheduler.wait_for(task) for task in tasks]

That's straightforward enough that maybe it doesn't even need
to be a library function, just a well-known pattern.

> Maybe you meant condition variable? It looks like threading.Condition
> with notify_all().

Something like that -- the terminology probably varies a bit
from one library to another. The basic concept is "set of
tasks waiting for some condition to become true".

> Anyway, I agree we need some primitives like these, but I'm not sure
> how to choose the set of essentials.

I think that most, maybe all, of the standard synchronisation
mechanisms, like mutexes and semaphores, can be built out of the
primitives I've already introduced -- essentially just block()
and yield. So anything of this kind that we provide will be more
in the way of convenience features than essential primitives.

-- 
Greg