Share on Mastodon
Series: asyncio basics, large numbers in parallel, parallel HTTP requests, adding to stdlib
Update: see the Python Async Basics video on this topic.
Python 3’s asyncio module and the async and await keywords combine to allow us to do cooperative concurrent programming, where a code path voluntarily yields control to a scheduler, trusting that it will get control back when some resource has become available (or just when the scheduler feels like it). This way of programming can be very confusing, and has been popularised by Twisted in the Python world, and nodejs (among others) in other worlds.
I have been trying to get my head around the basic ideas as they surface in Python 3’s model. Below are some definitions and explanations that have been useful to me as I tried to grasp how it all works.
Futures and coroutines are both things that you can wait for.
You can make a coroutine by declaring it with async def:
import asyncio async def mycoro(number): print("Starting %d" % number) await asyncio.sleep(1) print("Finishing %d" % number) return str(number)
Almost always, a coroutine will await something such as some blocking IO. (Above we just sleep for a second.) When we await, we actually yield control to the scheduler so it can do other work and wake us up later, when something interesting has happened.
You can make a future out of a coroutine, but often you don’t need to. Bear in mind that if you do want to make a future, you should use ensure_future, but this actually runs what you pass to it – it doesn’t just create a future:
myfuture1 = asyncio.ensure_future(mycoro(1))
# Runs mycoro!
But, to get its result, you must wait for it – it is only scheduled in the background:
# Assume mycoro is defined as above
myfuture1 = asyncio.ensure_future(mycoro(1))
# We end the program without waiting for the future to finish
So the above fails like this:
$ python3 ./python-async.py
Task was destroyed but it is pending!
task: <Task pending coro=<mycoro() running at ./python-async:10>>
sys:1: RuntimeWarning: coroutine 'mycoro' was never awaited
The right way to block waiting for a future outside of a coroutine is to ask the event loop to do it:
# Keep on assuming mycoro is defined as above for all the examples
myfuture1 = asyncio.ensure_future(mycoro(1))
loop = asyncio.get_event_loop()
loop.run_until_complete(myfuture1)
loop.close()
Now this works properly (although we’re not yet getting any benefit from being asynchronous):
$ python3 python-async.py Starting 1 Finishing 1
To run several things concurrently, we make a future that is the combination of several other futures. asyncio can make a future like that out of coroutines using asyncio.gather:
several_futures = asyncio.gather(
mycoro(1), mycoro(2), mycoro(3))
loop = asyncio.get_event_loop()
print(loop.run_until_complete(several_futures))
loop.close()
The three coroutines all run at the same time, so this only takes about 1 second to run, even though we are running 3 tasks, each of which takes 1 second:
$ python3 python-async.py Starting 3 Starting 1 Starting 2 Finishing 3 Finishing 1 Finishing 2 ['1', '2', '3']
asyncio.gather won’t necessarily run your coroutines in order, but it will return a list of results in the same order as its input.
Notice also that run_until_complete returns the result of the future created by gather – a list of all the results from the individual coroutines.
To do the next bit we need to know how to call a coroutine from a coroutine. As we’ve already seen, just calling a coroutine in the normal Python way doesn’t run it, but gives you back a “coroutine object”. To actually run the code, we need to wait for it. When we want to block everything until we have a result, we can use something like run_until_complete but in an async context we want to yield control to the scheduler and let it give us back control when the coroutine has finished. We do that by using await:
import asyncio
async def f2():
print("start f2")
await asyncio.sleep(1)
print("stop f2")
async def f1():
print("start f1")
await f2()
print("stop f1")
loop = asyncio.get_event_loop()
loop.run_until_complete(f1())
loop.close()
This prints:
$ python3 python-async.py start f1 start f2 stop f2 stop f1
Now we know how to call a coroutine from inside a coroutine, we can continue.
We have seen that asyncio.gather takes in some futures/coroutines and returns a future that collects their results (in order).
If, instead, you want to get results as soon as they are available, you need to write a second coroutine that deals with each result by looping through the results of asyncio.as_completed and awaiting each one.
# Keep on assuming mycoro is defined as at the top
async def print_when_done(tasks):
for res in asyncio.as_completed(tasks):
print("Result %s" % await res)
coros = [mycoro(1), mycoro(2), mycoro(3)]
loop = asyncio.get_event_loop()
loop.run_until_complete(print_when_done(coros))
loop.close()
This prints:
$ python3 python-async.py Starting 1 Starting 3 Starting 2 Finishing 3 Result 3 Finishing 2 Result 2 Finishing 1 Result 1
Notice that task 3 finishes first and its result is printed, even though tasks 1 and 2 are still running.
asyncio.as_completed returns an iterable sequence of futures, each of which must be awaited, so it must run inside a coroutine, which must be waited for too.
The argument to asyncio.as_completed has to be a list of coroutines or futures, not an iterable, so you can’t use it with a very large list of items that won’t fit in memory.
Side note: if we want to work with very large lists, asyncio.wait won’t help us here – it also takes a list of futures and waits for all of them to complete (like gather), or, with other arguments, for one of them to complete or one of them to fail. It then returns two sets of futures: done and not-done. Each of these must be awaited to get their results, so:
asyncio.gather
# is roughly equivalent to:
async def mygather(*args):
ret = []
for r in (await asyncio.wait(args))[0]:
ret.append(await r)
return ret
Further reading: realpython.com/async-io-python (a very complete and clear explanation, with lots of links)
I am interested in running very large numbers of tasks with limited concurrency – see the next article for how I managed it.