[Python-ideas] async/await in Python

[Yury Selivanov]

Chris,

On 2015-04-18 5:29 PM, Chris Angelico wrote:
> On Sun, Apr 19, 2015 at 3:39 AM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
>> The internal implementation based on generators is something
>> that was absolutely required to cover in the PEP in a great detail,
>> but almost everybody will forget about that fact pretty soon.
>>
>> The point of this PEP is to actually avoid any confusion, and
>> to just have two separate concepts: coroutines and generators
>> (the latter can still be used as a "coroutine-like" object,
>> but hopefully nobody will do that at some point).
> Which means that these are three very VERY different things, all of
> which happen to be implemented (under the covers) using similar
> mechanisms:
>
> async def corout():
>      await spam()
>
> def gen():
>      yield from [1,2,3]
>
> class iter:
>      def __init__(self): self.state = 0
>      def __iter__(self): return self
>      def __next__(self):
>          if self.state == 3: raise StopIteration
>          self.state += 1
>          return self.state
>
> Technically, a generator object is an iterator, and a coroutine is a
> generator, but they're really implementation details. PEP 479 is all
> about not expecting "raise StopIteration" to terminate gen(); in the
> same way, programmers should not expect "for x in corout()" to do
> anything meaningful, because they're completely different things.
>
> Have I understood this correctly?

Yes, you're correct, 'for x in coroutine()' shouldn't
do anything meaningful in the client code, but it's important
to allow this in an event loop (or at least to allow .send() and
.throw() methods of coroutine object).

As of now, the PEP and reference implementation allow using
iter() built-in and for..in statements on coroutine-objects.

I was going to raise this question next week, when I gather
the initial feedback (I have a branch where this restriction
is implemented, so it's at least possible).

Best,
Yury