Asyncio - Asynchronous programming with coroutines - Intermediate Python Programming p.26

Asyncio’s core value is letting Python overlap waiting time across multiple tasks—so one slow I/O operation doesn’t freeze everything else. The tutorial contrasts synchronous execution (tasks run to completion in order) with asynchronous concurrency (tasks can be suspended and resumed), using a web-page loading example: if an image request stalls, synchronous code would hang the whole page, while asynchronous code can keep rendering other elements during the latency.

To make that concrete, the lesson starts with a deliberately CPU-ish function that finds numbers divisible by a given divisor within a range, then measures how long three calls take when run sequentially. In the synchronous version, the script runs each computation in order, so the total time is essentially the sum of the three runs. The motivation for async appears when one of the tasks becomes “slow” (in real life, that slowness usually comes from waiting on external I/O like network responses). The tutorial argues that concurrency is not parallelism: tasks don’t run simultaneously on multiple cores; instead, the event loop switches between tasks when one is waiting.

The conversion to asyncio begins with syntax: changing `def` to `async def` marks a coroutine, and importing `asyncio` provides the primitives needed for scheduling and suspension. Next comes the event loop. The code initializes it with `asyncio.get_event_loop()`, then runs the main coroutine until completion via `loop.run_until_complete(main)`, and finally closes the loop. Inside the loop, the lesson schedules work with `loop.create_task(...)`, creating separate tasks for the three coroutine calls.

A key turning point comes when the tutorial shows why “async” alone doesn’t guarantee speed. Even with coroutines and tasks, if the coroutine never hits an awaitable pause, the program still behaves like synchronous code—because there’s no moment for the event loop to switch contexts. To demonstrate the mechanism, the function adds a tiny `await asyncio.sleep(...)` when a certain condition is met (e.g., when the loop index hits a specific modulus). That artificial suspension allows other tasks to progress while one task is “waiting,” producing the expected interleaving.

The lesson also highlights trade-offs: even very small sleeps introduce overhead, and the event loop can only switch tasks at await points. It then shows how to retrieve results correctly. `run_until_complete` returns task result objects, but the actual computed values live in `result()` (e.g., `d1.results`). Finally, it covers common mistakes: forgetting to await results can cause tasks to be dispatched and then the program exits before they finish, leading to warnings like “task got destroyed.” Another frequent error is forgetting the required `async` keyword, which triggers syntax errors.

The takeaway is practical: asyncio is most effective when tasks spend time waiting on I/O, and real-world async HTTP workloads are a common fit—hence the suggestion to look at `aiohttp` for asynchronous web requests.