Why do two `await` calls written one after another run sequentially, not concurrently?

### What `await` promises `await x` says two things at once, and interviews probe whether a candidate has separated them. 1. **To the coroutine executing it:** stop here. The next statement does not run until `x` has completed and its result is available. In that respect `await` behaves exactly like a blocking call - the code reads top to bottom and means what it looks like. 2. **To the event loop:** this coroutine is parked and its thread is free. While it is suspended, the loop may resume anything *else* it already has scheduled and ready. The second promise is the whole point of asyncio, and it is also what gets over-read. Suspension frees the *thread*, not the *statement order*. Nothing in `await` starts anything early, runs the next line ahead of time, or overlaps two awaits in the same coroutine. ### The arithmetic that follows ```python async def main(): a = await load_a() # 300 ms b = await load_b() # 300 ms return a, b # done after ~600 ms ``` That coroutine takes about 600 ms. It is not slower than the synchronous version, and - crucially - it is not faster either. If nothing else is scheduled on the loop, those 600 ms are 600 ms of an idle thread. The same reasoning applies to the shape people write most often: ```python results = [] for url in urls: results.append(await fetch(url)) # strictly serial ``` One hundred 50 ms fetches take five seconds. Rewriting the loop with `async def` and `await` changed the syntax and not the timeline. ### Why the illusion is so persistent Three things feed it. First, the word *async* suggests "in the background", when here it only means "can suspend". Second, most tutorials show `await asyncio.sleep(...)` inside code that already has several tasks running, so the reader attributes the overlap to `await` instead of to the scheduling. Third, an `await` really can let a whole program go faster - just not through this coroutine's own statements. Under a server handling many connections, each handler's `await` is what lets the other handlers make progress. The concurrency comes from there being many handlers scheduled, not from the `await` keyword. ### What concurrency actually requires To overlap two operations, both must be *scheduled units* known to the loop at the same time. In asyncio that means wrapping coroutines in tasks - `asyncio.create_task`, `asyncio.gather`, or an `asyncio.TaskGroup` block - and then awaiting the aggregate. The details of those constructs, their exception behaviour and how to keep references to running tasks are their own subject; the point that belongs here is the boundary: **`await` composes, scheduling parallelises.** A single `await` on a single awaitable can never be concurrent with anything else in the same coroutine, no matter what it is awaiting. ### The subtler failure: an await that never suspends Suspension is not guaranteed by writing `await`. If the awaited coroutine completes without ever reaching a real suspension point - a cache hit, a value already available, an `asyncio.Future` that is already done - control returns without ever handing back to the loop. A tight loop of such awaits starves every other task even though the code is littered with `await` keywords. Conversely, `await asyncio.sleep(0)` is the idiom for deliberately yielding one turn to the loop without waiting for anything. The lesson is that `await` marks a *possible* suspension point, not a guaranteed one. ### Function colouring, in one paragraph Because `await` is only legal inside `async def`, making one function async forces every caller that wants its result to be async too, all the way up to a top-level `asyncio.run`. That is the "colouring" split: sync and async versions of the same call graph do not compose, and a codebase tends to grow duplicated pairs or a hard boundary where blocking work is pushed off the loop with `asyncio.to_thread`. Recognising that the ripple is a consequence of `await`'s sequential, in-coroutine semantics - not an accident of the library - is what a middle-level answer is expected to reach.