[Async-sig] PEP: asynchronous generators

[Andrew Svetlov]

Ok, if the implementation gets `asend()` etc. "for free" I support it.

On Fri, Jul 29, 2016 at 9:14 PM Yury Selivanov <yselivanov at gmail.com> wrote:

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

-- 
Thanks,
Andrew Svetlov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20160729/66cf18bd/attachment.html>