Yury this looks great! Thanks for suggesting this. One of the big problems I've seen with the basic approachability of async/await in Python is the lack of interpreter support. Now this makes that a lot easier by having a one function you can use makes this a lot easier (One of the main things I use `curio` for is simply being able to `curio.run` an Awaitable in the interpreter without having to go through the normal asyncio dance). I would love to see if we could extend this even further to making `await` "Just Work" in the interpreter.
Thanks, Roy On Wed, Nov 16, 2016 at 12:53 PM, Yury Selivanov <yseliva...@gmail.com> wrote: > > > On Nov 16, 2016, at 3:35 PM, Nathaniel Smith <n...@pobox.com> wrote: > > > > What's the use case for the async generator version? Could the yield be > replaced by 'await loop.shutting_down()’? > > Async generator version (inspired by contextlib.contextmanager decorator) > is needed in cases where you want loop.run_forever. > > The PR originally proposed to add `asyncio.forever()` (which is the same > idea as `loop.shutting_down()`), but nobody particularly liked it. > > A couple of thoughts/reasons: > > 1. Some pretty intrusive modifications are required to be made in the > event loop to make it work. That means all other event loops (including > uvloop) will have to be modified to support it. This is the most important > reason. > > 2. `loop.shutting_down()` is a no go because it’s a method on the loop > object. We can discuss `asyncio.shutting_down`. The whole point of this > discussion is to get rid of the event loop. > > 3. `await forever()` and `await shutting_down()` have a naming issue - > both look weird: > > async def main(): > srv = await asyncio.start_server(…) > try: > await asyncio.shutting_down() # or await forever() > finally: > srv.close() > await srv.wait_closed() > > In the above example, what does the second ‘await’ do? Will it be > resolved when the loop is stopped with ‘loop.stop()’? Or when a > KeyboardInterrupt occurs? What will happen if you await on it in parallel > from 10 different coroutines? It’s just difficult to define a clear > semantics of this coroutine. > > Using an asynchronous generator for this case is easier in terms of > implementation and in terms of specifying the execution semantics. And the > approach of using generators for such things isn’t new - we have > contextlib.contextmanager decorator which is quite popular. > > Yury > _______________________________________________ > 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/ >
_______________________________________________ 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/
