[Python-ideas] PEP 525: Asynchronous Generators

[Alexander Shorin]

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/