[Python-ideas] PEP 525: Asynchronous Generators

[Nick Coghlan]

On 7 August 2016 at 02:51, 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)
>


Good point. Let's make adding that part of the PEP, since it will be
useful, makes it immediately obvious why we're including asend() and
athrow(), and will also stress test the coroutine traceback machinery in an
interesting way. (Note that depending on the implementation details, it may
need to end up living in asyncio somewhere - that will depend on whether or
not we need to use any asyncio APIs in the implementation of
_CoroutineContextManager)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160808/fd45a915/attachment.html>