Ok, if the implementation gets `asend()` etc. "for free" I support it.
On Fri, Jul 29, 2016 at 9:14 PM Yury Selivanov <yseliva...@gmail.com> wrote: > > > On Jul 29, 2016, at 3:06 PM, Andrew Svetlov <andrew.svet...@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
_______________________________________________ Async-sig mailing list Async-sig@python.org https://mail.python.org/mailman/listinfo/async-sig Code of Conduct: https://www.python.org/psf/codeofconduct/