Built-in function to run coroutines
Hi, async/await syntax is a very nice recent feature, but there is something that I miss for coroutines defined with async def, as compared to generators. Coroutines represent an interesting mental model that goes beyond only asynchronous IO, so that I play with them in REPL often. But there is no built-in function to actually run a coroutine, so that typically I use something like:
def run(coro): ... try: ... coro.send(None) ... except StopIteration as e: ... return e.value
async def f(): ... return 42
run(f()) 42
There is a simple yet useful function for interactive play with generators - ``next``, but not for coroutines. There is an option to do:
import asyncio loop = asyncio.get_event_loop() loop.run_until_complete(f()) 42
But this feels a bit redundant for an interactive play. I would propose to add something like an above described ``run`` function to built-ins. Yes, I know, there is a very high bar for adding a built-in function, but I believe such a function will help to promote async/await to a wider community (especially to novices). -- Ivan
On other hand having builtin for making toy examples in interactive mode looks very redundant. On Sat, Nov 12, 2016 at 10:38 PM Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
Hi,
async/await syntax is a very nice recent feature, but there is something that I miss for coroutines defined with async def, as compared to generators. Coroutines represent an interesting mental model that goes beyond only asynchronous IO, so that I play with them in REPL often. But there is no built-in function to actually run a coroutine, so that typically I use something like:
def run(coro): ... try: ... coro.send(None) ... except StopIteration as e: ... return e.value
async def f(): ... return 42
run(f()) 42
There is a simple yet useful function for interactive play with generators - ``next``, but not for coroutines. There is an option to do:
import asyncio loop = asyncio.get_event_loop() loop.run_until_complete(f()) 42
But this feels a bit redundant for an interactive play. I would propose to add something like an above described ``run`` function to built-ins.
Yes, I know, there is a very high bar for adding a built-in function, but I believe such a function will help to promote async/await to a wider community (especially to novices).
-- Ivan
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Thanks, Andrew Svetlov
I think there's a plan to add a run() function to asyncio, which would be something akin to def run(coro): return get_event_loop().run_until_complete(coro) (but perhaps with better cleanup). Then you could start with `from asyncio import run` and from then on you'd have your handy little function. When using standard Python you can even put such handy imports in your $PYTHONSTARTUP file. Presumably with Jupyter there are other, more powerful mechanisms. --Guido On Sat, Nov 12, 2016 at 12:45 PM, Andrew Svetlov <andrew.svetlov@gmail.com> wrote:
On other hand having builtin for making toy examples in interactive mode looks very redundant.
On Sat, Nov 12, 2016 at 10:38 PM Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
Hi,
async/await syntax is a very nice recent feature, but there is something that I miss for coroutines defined with async def, as compared to generators. Coroutines represent an interesting mental model that goes beyond only asynchronous IO, so that I play with them in REPL often. But there is no built-in function to actually run a coroutine, so that typically I use something like:
def run(coro): ... try: ... coro.send(None) ... except StopIteration as e: ... return e.value
async def f(): ... return 42
run(f()) 42
There is a simple yet useful function for interactive play with generators - ``next``, but not for coroutines. There is an option to do:
import asyncio loop = asyncio.get_event_loop() loop.run_until_complete(f()) 42
But this feels a bit redundant for an interactive play. I would propose to add something like an above described ``run`` function to built-ins.
Yes, I know, there is a very high bar for adding a built-in function, but I believe such a function will help to promote async/await to a wider community (especially to novices).
-- Ivan
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Thanks, Andrew Svetlov
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)
Hi Guido, On 2016-11-12 4:24 PM, Guido van Rossum wrote:
I think there's a plan to add a run() function to asyncio, which would be something akin to
def run(coro): return get_event_loop().run_until_complete(coro)
(but perhaps with better cleanup).
Please see https://github.com/python/asyncio/pull/465. Yury
What about making "run" an instance method of coroutines? On 14.11.2016 19:30, Yury Selivanov wrote:
Hi Guido,
On 2016-11-12 4:24 PM, Guido van Rossum wrote:
I think there's a plan to add a run() function to asyncio, which would be something akin to
def run(coro): return get_event_loop().run_until_complete(coro)
(but perhaps with better cleanup).
Please see https://github.com/python/asyncio/pull/465.
Best, Sven
On 2016-11-14 1:35 PM, Sven R. Kunze wrote:
What about making "run" an instance method of coroutines?
That would require coroutines to be aware of the loop that is running them. Not having them aware of that is what makes the design simple and allows alternatives to asyncio. All in all I'd be strong -1 to do that. Yury
On 15 November 2016 at 04:39, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
On 2016-11-14 1:35 PM, Sven R. Kunze wrote:
What about making "run" an instance method of coroutines?
That would require coroutines to be aware of the loop that is running them. Not having them aware of that is what makes the design simple and allows alternatives to asyncio.
It also helps minimise the additional work needed for Tornado, Cython, etc to provide their own coroutine implementations. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (6)
-
Andrew Svetlov -
Guido van Rossum -
Ivan Levkivskyi -
Nick Coghlan -
Sven R. Kunze -
Yury Selivanov