[Async-sig] PEP: asynchronous generators

[Yury Selivanov]

> On Jul 29, 2016, at 3:06 PM, Andrew Svetlov <andrew.svetlov at gmail.com> wrote:
> 
> I'm personally think that `a` prefix is pretty fine and understandable.
> 
> Do we really need to implement full PEP-342 spec in async way?
> What are use cases?
> My first thought is PEP-255-like simple async generators should be enough.
> 
> Full PEP-342 styled generators are clue for implementing things like twisted.inlineCallback and tornado.gen.
> 
> Thanks to PEP-492 we don't need it anymore.
> 
> All my requirements are covered perfectly fine by existing `__aiter__`/`__anext__`.
> What I really need is allowing to write just `yield val` from coroutine but never need for `resp = yield req`

There are a few reasons for having asend() and athrow():

1) They will have to be implemented regardless; aclose() is a slightly limited version of athrow(), and __anext__() is almost the same thing as asend().  It’s 5-10 additional lines of code to have them.

2) __anext__() has to be a generator-like object, so that YIELD_FROM opcode works correctly with it. That means it has to implement ‘send()’ and ‘throw()’ methods.  Which, in turn, means that even if we don’t expose ‘agen.athrow()’, people would be able to do ‘agen.__anext__().throw()’.  But that’s a very error-prone thing to do.

3) Having ‘anext()’ and ‘athrow()’ enable you to implement decorators like `@contextlib.contextmanager` but for ‘async with’.  And I’m pretty sure that people will come up with even more creative things.

To conclude, having ‘asend()’ and ‘athrow()’ doesn’t complicate the implementation at all, but makes asynchronous generators consistent and more compatible with synchronous generators, which I don’t think is a bad thing.

Yury