<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 7 August 2016 at 02:51, Yury Selivanov <span dir="ltr"><<a href="mailto:yselivanov.ml@gmail.com" target="_blank">yselivanov.ml@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Nick,<span class=""><br>
<br>
On 2016-08-06 4:28 AM, Nick Coghlan wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 6 August 2016 at 01:11, Andrew Svetlov <<a href="mailto:andrew.svetlov@gmail.com" target="_blank">andrew.svetlov@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Honestly I personally don't feel a need for two-way generators with<br>
`asend()`/`athrow()` but as Yury explained he need them internally for<br>
`anext`/`aclose` anyway.<br>
</blockquote>
Even if asend()/athrow() are cheap from an implementation perspective,<br>
they're *not* necessarily cheap from a "cognitive burden of learning<br>
the API" perspective. We know what send() and throw() on generators<br>
are for: implementing coroutines. However, we also know that layering<br>
that on top of the generator protocol turned out to be inherently<br>
confusing, hence PEP 492 and async/await.<br>
<br>
So if we don't have a concrete use case for "coroutine coroutines"<br>
(what does that even *mean*?), we shouldn't add asend()/athrow() just<br>
because it's easy to do so.<br>
</blockquote>
<br></span>
One immediate use case that comes to mind is<br>
@contextlib.asynccontextmanage<wbr>r<br>
<br>
Essentially this:<br>
<br>
  @contextlib.asynccontextmanage<wbr>r<br>
  async def ctx():<br>
    resource = await acquire()<br>
    try:<br>
      yield resource<br>
    finally:<br>
      await release(resource)<br></blockquote><div><br><br></div><div>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)<br><br></div><div>Cheers,<br></div><div>Nick.<br></div></div><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>