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

[Guido van Rossum]

On Mon, Oct 15, 2012 at 10:39 PM, Greg Ewing
<greg.ewing at canterbury.ac.nz> wrote:
> Nick Coghlan wrote:
>>
>> (this is why I disagree with Greg that
>> "yield from" can serve as the one true API - it doesn't handle partial
>> iteration, and it doesn't handle pre- or post- processing around the
>> suspension points while iterating).
>
>
> I'm aware of the iteration problem, but I'm not convinced
> that the convolutions necessary to make it possible to use
> a for-loop for this are worth the bother, as opposed to
> simply accepting that you can't use the for statement in
> this situation, and using some other kind of loop.
>
> In any case, even if we decide to provide a scheduler
> instruction to enable using for-loops on suspendable
> iterators somehow, it doesn't follow that we should use
> scheduler instructions for anything *else*.

I don't see how we could ever have  a for-loop that yields on every
iteration step. The for-loop never uses yield. Thus there can be no
direct equivalent to as_completed() in the PEP 380 or PEP 342
coroutine worlds.

> I would consider such a scheduler instruction to be a stopgap
> measure until we can find a better solution -- just as
> yield-from is a better solution than using "call" and "return"
> scheduler instructions.

I can already see the armchair language designers race to propose
syntax the puts a yield keyword in the for-loop syntax at a point
where it is currently not allowed. Let's nip that in the bud and focus
on something that can work with Python 3.3.

-- 
--Guido van Rossum (python.org/~guido)