Async/Await in Python

This is the opening map for async/await, and the framing matters: the goal is to fix the shape of the idea in your head before any syntax. The single most useful sentence is that your program spends most of its life waiting on something external, and async is the tool for spending that wait productively.

Throughout this post we deliberately separate three things people conflate: the coroutine (the pausable unit of work), the event loop (the scheduler that runs coroutines), and await (the keyword that marks where a pause can happen). Keeping them distinct is what makes the rest of the series click.

A coroutine is the atom of async programming. Defined with 'async def', it is special because it can suspend in the middle and resume later from the exact same spot, with all its local variables intact. That ability to freeze and thaw is what lets one thread juggle many jobs.

The subtle point beginners miss is that calling a coroutine does not run it. 'greet("Sam")' returns a coroutine object — a description of work, not the work itself. Something has to drive it: usually the event loop via asyncio.run, an await, or create_task. Until then it just sits there, inert.

await is the heart of the model and its name is slightly misleading. It does not mean 'block here until done' in the threading sense — it means 'this operation may take time, so suspend me and let the event loop run other tasks until my result is ready.' The pause is cooperative: your coroutine voluntarily steps aside.

await is only legal inside an async function, and it can only be applied to an awaitable — a coroutine, a Task, or a Future. That constraint is the source of async's 'contagious' reputation: to await something, the awaiting function must itself be async, which tends to pull async up the call chain.

This slide shows the minimal complete program so the pieces have a home. 'async def greet' defines the coroutine. Inside it, 'await asyncio.sleep(1)' is the suspension point — a stand-in for any real I/O wait. asyncio.run is the entry point that creates an event loop, runs the coroutine to completion, and tears the loop down.

Note the asymmetry that trips people up: print runs synchronously and immediately, but the await line is where control could leave this function. If other tasks were scheduled, they would get their turn during that one-second sleep. With only one task here, nothing else runs — but the machinery is identical.

The event loop is the conductor. It maintains a set of tasks, picks one that is ready, and runs it until that task hits an await and yields. Then it parks the task against whatever it is waiting on and picks the next ready task. This is cooperative scheduling: the loop can only switch at await points, never in the middle of a synchronous run.

asyncio.run is the typical way to start a loop for a program: it builds a fresh loop, drives your top-level coroutine until it finishes, and then cleanly shuts everything down. You rarely manage the loop by hand; you hand it a coroutine and let it orchestrate.

The cycle diagram captures the loop's heartbeat: pick a ready task, run it until an await, park it while its I/O is pending, switch to another ready task, and repeat forever until everything is done. The key insight is that 'park' and 'switch' are nearly free — parking a task is just bookkeeping, not a thread context switch.

This is why async scales to huge numbers of concurrent waits. Each parked task costs a little memory and a loop entry, not an OS thread. Ten thousand connections waiting on the network are ten thousand cheap bookmarks, not ten thousand expensive threads.

Concurrency and parallelism get used interchangeably but they are different. Concurrency is about structure — dealing with many things at once by interleaving them. Parallelism is about execution — doing many things at literally the same instant on multiple cores. Async gives you concurrency on a single thread; it does not give you parallelism.

That distinction dictates the tool. For I/O-bound work, where tasks spend their time waiting, interleaving on one thread is ideal and async shines. For CPU-bound work, where tasks are actually computing, you need real parallelism via multiprocessing to use more than one core, because Python's GIL prevents threads from running Python bytecode simultaneously.

This is the counterintuitive promise: a single thread, handling thousands of clients, faster overall than the obvious sequential approach. The trick is that async never makes any individual task quicker — a 200ms API call still takes 200ms. What it removes is the idle time between and during waits.

While one task waits on the network, the loop runs others that are ready. Stack enough waiting tasks and their waits overlap almost completely, so total wall-clock time collapses toward the duration of the single slowest operation rather than the sum of them all. That overlap is the entire economic case for async.

The coroutine-versus-task distinction is where 'doing things at the same time' actually lives, and it is worth pinning down early. A bare coroutine object does nothing until driven. awaiting it runs it inline — your current coroutine waits right there for it to finish, which is sequential.

asyncio.create_task wraps the coroutine in a Task and registers it with the loop so it can run concurrently with the code that created it. This is the difference between 'do this and wait' and 'start this running alongside me.' gather is the common convenience that schedules many coroutines as tasks and waits for the whole batch. Internalize this and the concurrency patterns in later posts are obvious.

These five lines are the portable mental model. 'async def is a pausable function' captures coroutines. 'await is pause here, let others run' captures the suspension semantics. 'event loop is the turn-taking scheduler' captures the runtime. 'concurrency is overlap, not more cores' guards against the parallelism confusion. 'best when you're waiting on I/O' tells you when to even reach for it.

If you only remember these five lines you can reason about most async code correctly, even before you have memorized the API. The syntax is just a faithful encoding of these ideas.

The most expensive misconception is that async is a general speed-up button. It is not. Async only helps when there is waiting to overlap. If your workload is pure computation — number crunching, parsing, image processing — there are no awaits where the loop can switch, so you get the overhead of the machinery and none of the benefit.

The correct diagnosis comes first: is your bottleneck I/O or CPU? I/O-bound means async or threads. CPU-bound means multiprocessing or offloading to native code. Reaching for async on a CPU-bound problem is a classic mistake that makes code more complex and no faster, sometimes slower.

That wraps the concept post: you now have coroutine, await, and event loop as three distinct, named things, plus the crucial concurrency-versus-parallelism boundary and a clear sense of when async is even the right call.

Day 23 of this slot shifts from 'what it is' to 'why it matters' — the concrete throughput and scaling wins that make async worth the extra mental overhead in real production systems.