How Do async and await Work in Python?

async def defines a coroutine function. Calling it does not run the body — it creates a coroutine object that has to be driven by an event loop. await inside that body is a suspension point: the coroutine hands control back to the loop, which can run other ready tasks in the meantime, and the coroutine resumes later when its awaited operation is finished.

The event loop is what makes it work. It keeps a set of tasks that are ready to run and a set of callbacks waiting on I/O. When a task awaits a socket read, the loop registers interest in that socket and moves on to the next ready task; when the socket becomes readable, the task is scheduled again. Thousands of tasks can be in flight in one thread, because a task is cheap — just a coroutine plus its state — unlike a thread with its own stack.

So when do you reach for it? When you have a lot of concurrent I/O and you want one thread rather than hundreds. An async web server handling thousands of connections, a script fetching many URLs at once, or a client talking to several services in parallel are the classic cases. The rule of thumb is that asyncio is for concurrency, not parallelism — it overlaps waiting, it does not compute faster.

Two practical points for an interview. Never call a blocking function inside a coroutine, because it blocks the whole event loop — use an async version, or push the blocking work into a thread with asyncio.to_thread. And asyncio.gather lets you await several coroutines at once, which is usually the reason you reach for asyncio in the first place.

A coroutine is defined with async def and driven by asyncio.run.

import asyncio


async def fetch(name):
    await asyncio.sleep(0.1)
    return f"data for {name}"


async def main():
    result = await fetch("Ada")
    print(result)


asyncio.run(main())

The output is data for Ada. The mechanism is worth describing precisely. Calling fetch("Ada") creates a coroutine object and returns it immediately — no code inside fetch has run yet. asyncio.run takes that coroutine, creates an event loop, and starts running it. When the coroutine reaches the await on asyncio.sleep, it suspends and the loop regains control; the sleep schedules a timer callback, and when the timer fires the coroutine is resumed and the return value is passed back through the await. Only then does main print the result.

Two details about the syntax. await can only be used inside an async function — using it in a normal def raises a SyntaxError. And the return value comes back as the result of the await expression, which is why result is bound to the string rather than the coroutine itself.

asyncio.run is the modern entry point because it handles the loop's creation and cleanup for you. The older style — creating a loop with asyncio.get_event_loop, running the coroutine with loop.run_until_complete and then closing the loop — is what you will see in older tutorials, and it is worth knowing why it existed but not worth copying.

gather awaits several awaitables at once, so the tasks interleave while they are waiting.

import asyncio
import time


async def task(name, delay):
    await asyncio.sleep(delay)
    return f"{name} finished after {delay}s"


async def main():
    start = time.perf_counter()
    results = await asyncio.gather(task("fast", 0.1), task("slow", 0.3))
    elapsed = time.perf_counter() - start
    print(results)
    print(f"total {elapsed:.2f}s")


asyncio.run(main())

The results list comes back in the order the tasks were given, not in the order they finished, and the total time is about 0.30 seconds rather than 0.40. The two sleeps overlap: while the fast task is waiting, the slow one is waiting too, and the event loop wakes each one up when its timer expires.

The ordering rule is worth knowing because it catches people out. gather returns the results in the order of the arguments, so if you need completion order instead, asyncio.as_completed gives you an iterator that yields tasks as they finish. And gather has a return_exceptions flag — when it is true, a failing task returns its exception as a result instead of cancelling the others, which is usually what you want when the tasks are independent.

One caution for an interview. The concurrency is real but the parallelism is not — everything runs in one thread, so if the coroutines do CPU-bound work the event loop will block. asyncio overlaps waiting, it does not compute faster.