[Python-ideas] PEP 525: Asynchronous Generators

[Andrew Svetlov]

 @contextlib.asynccontextmanager and especially an alternative for
asyncio.Queue looks like valuable examples for asend/athrow.

On Sun, Aug 7, 2016 at 12:21 AM Alexander Shorin <kxepal at gmail.com> wrote:

> While Nick has a point about coroutine coroutines confusion. I
> consider asend/athow will be useful in real world. Because they
> provide stable, well known and uniform interface to communicate with a
> coroutine.
>
> For now to have two-way communication with some coroutine you have to
> establish two queues: inbox and outbox, pass them around, don't
> eventually mess them and so on. Queues are great for message-passing
> communication and generally good idea to use, but it still some
> boilerplate code as like as __aiter__/__anext__ (which async
> generators will get rid) to maintain.  Also queue is a bad reference
> to a coroutine owns it - it's hard to find own who is really reading
> that inbox in complex codebase.
>
> With asend/athrow there will be no need to plass queues around, but
> just coroutine instance and do all the communication with it as with
> plain object. You need to retrieve a value - do iterate over it; need
> to send a value back - do asend. Termination and error-passing are
> aslo easy to do.
>
> So while this interface looks complicated for learning curve, it could
> be very helpful, when you need simple communication channel between
> coroutines sized equals one. For something greater you have to return
> to queues approach, but they involve quite a lot of else bits to care
> about like queue overflow, which is indeed topic for advanced users.
>
>
>
> --
> ,,,^..^,,,
>
>
> On Sat, Aug 6, 2016 at 7:51 PM, Yury Selivanov <yselivanov.ml at gmail.com>
> wrote:
> > Hi Nick,
> >
> > On 2016-08-06 4:28 AM, Nick Coghlan wrote:
> >
> >> On 6 August 2016 at 01:11, Andrew Svetlov <andrew.svetlov at gmail.com>
> >> wrote:
> >>>
> >>> Honestly I personally don't feel a need for two-way generators with
> >>> `asend()`/`athrow()` but as Yury explained he need them internally for
> >>> `anext`/`aclose` anyway.
> >>
> >> Even if asend()/athrow() are cheap from an implementation perspective,
> >> they're *not* necessarily cheap from a "cognitive burden of learning
> >> the API" perspective. We know what send() and throw() on generators
> >> are for: implementing coroutines. However, we also know that layering
> >> that on top of the generator protocol turned out to be inherently
> >> confusing, hence PEP 492 and async/await.
> >>
> >> So if we don't have a concrete use case for "coroutine coroutines"
> >> (what does that even *mean*?), we shouldn't add asend()/athrow() just
> >> because it's easy to do so.
> >
> >
> > One immediate use case that comes to mind is
> > @contextlib.asynccontextmanager
> >
> > Essentially this:
> >
> >   @contextlib.asynccontextmanager
> >   async def ctx():
> >     resource = await acquire()
> >     try:
> >       yield resource
> >     finally:
> >       await release(resource)
> >
> > I'm also worrying that in order to do similar things people will
> > abuse "agen.__anext__().send()" and "agen.__anext__().throw()".
> > And this is a very error-prone thing to do.  For example, in
> > asyncio code, you will capture yielded Futures that the
> > generator is trying to await on (those yielded futures
> > have to be captured by the running Task object instead).
> >
> > "asend" and "athrow" know about iteration protocol and can see
> > the "wrapped" yielded objects, hence they can iterate the
> > generator correctly and reliably.
> >
> > I think Nathaniel Smith (CC-ed) had a few more use cases for
> > asend/athrow.
> >
> >
> >>
> >> If we wanted to hedge our bets, we could expose them as _asend() and
> >> _athrow() initially, on the grounds that doing so is cheap, and we're
> >> genuinely curious to see if anyone can find a non-toy use case for
> >> them. But we should be very reluctant to add them to the public API
> >> without a clear idea of why they're there.
> >
> >
> > I think we should decide if we want to expose them at all.
> > If we're in doubt, let's not do that at all.  Exposing them
> > with a "_" prefix doesn't free us from maintaining backwards
> > compatibility etc.
> >
> > You're completely right about the increased "cognitive burden
> > of learning the API".  On the other hand, send() and throw()
> > for sync generators were designed for power users; most
> > Python developers don't even know that they exist.  I think
> > we can view asend() and athrow() similarly.
> >
> > Thank you,
> > Yury
> >
> >
> >
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas at python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
Thanks,
Andrew Svetlov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160807/e1ac8746/attachment.html>