Imagine a backend service at a Hyderabad fintech that must call three partner APIs — a KYC provider, a credit bureau and a bank — before approving a loan. Each call takes about 400 milliseconds. Written the ordinary way, the three calls run one after another and the user waits 1.2 seconds. Written asynchronously, all three calls are in flight at the same time and the user waits about 400 milliseconds. Nothing got faster; the program simply stopped sitting idle while the network did its work. That idea — do not wait while you could be doing something else — is the whole point of concurrency.

Python offers three ways to achieve it: threads (threading), processes (multiprocessing) and coroutines (asyncio with async/await). They look similar from a distance but solve different problems, and choosing the wrong one is the most common concurrency mistake in Python codebases. A developer who uses threads for a CPU-heavy image pipeline sees no speedup because of the GIL; a developer who puts a blocking time.sleep inside an async def freezes an entire FastAPI server; a developer who spawns a process per HTTP request runs out of memory.

This lecture builds the mental model first — concurrency vs parallelism, what the GIL actually guards, what changed with the free-threaded builds in Python 3.13 and 3.14 — and then goes deep into asyncio: the event loop, asyncio.run, tasks, gather, TaskGroup, timeouts, cancellation, async HTTP with httpx, and bridging to thread and process pools with concurrent.futures. By the end you will be able to look at any workload and say with confidence: "this is I/O-bound, use asyncio" or "this is CPU-bound, use processes", and write the code correctly.

At the time of writing, Python 3.14 is the current stable series and Python 3.15 is arriving in October 2026. Every example in this lecture runs on Python 3.11 and newer; features tied to a specific version are labelled.

Concurrency means dealing with many tasks *in overlapping time periods*. Parallelism means literally executing many tasks *at the same instant* on different CPU cores. The classic analogy: one chef who keeps several dishes moving — stirring the dal while the rice boils — is concurrent. Four chefs each cooking one dish is parallel. The single chef is not doing two things at once; they are never idle while waiting, which is enough to finish dinner far sooner.

Why does this distinction matter so much in Python? Because the type of work decides which approach actually helps:

• I/O-bound work — waiting on the network, disk, a database or a subprocess. The CPU is idle most of the time. Here concurrency alone (one core, many waiting tasks) gives huge wins. Fetching 100 web pages that each take 300 ms drops from 30 seconds to under a second.
• CPU-bound work — hashing passwords, resizing images, running a pandas groupby over 50 million rows, training a model. The CPU is busy 100% of the time. Only true parallelism (more cores) helps; juggling tasks on a single core just adds overhead.

asyncio is a concurrency tool: a single thread, a single core, cooperatively switching between coroutines whenever one of them awaits. threading is also, in standard CPython, mostly a concurrency tool for Python code because of the GIL (next section), although C extensions and I/O release the GIL. multiprocessing and ProcessPoolExecutor give real parallelism by running separate interpreters on separate cores.

A useful measurement habit: run your function once, note the wall-clock time and the CPU time (time.process_time()). If CPU time is close to wall time, you are CPU-bound. If CPU time is tiny and wall time is large, you are I/O-bound and asyncio or threads will help.

The Global Interpreter Lock (GIL) is a mutex inside CPython that allows only one thread to execute Python bytecode at a time. It exists because CPython's memory management uses reference counting, and updating reference counts from many threads simultaneously without a lock would corrupt memory. The GIL made the interpreter simple and single-threaded code fast, at the cost of making multi-threaded *CPU-bound* Python code no faster than single-threaded code — four threads hashing passwords on a four-core machine still take as long as one thread, because they take turns holding the lock.

Important nuance: the GIL is released during blocking I/O (socket reads, file reads, time.sleep) and by many C extensions (NumPy, hashlib on large inputs, zlib). That is why threading still works well for I/O-bound programs and some numeric code, and why the GIL is not a problem for the majority of web backends.

Free-threaded Python (PEP 703): Python 3.13 (October 2024) shipped an alternative build of CPython, often called python3.13t, compiled with --disable-gil. In 3.13 this build was explicitly labelled experimental. In Python 3.14 the Steering Council accepted PEP 779 and the free-threaded build became officially supported — no longer experimental, but still optional: the default download is still the GIL build, you must install the free-threaded variant separately (for example via the python.org installer option, uv python install 3.14t or pyenv install 3.14t). Making free-threading the default (so-called Phase III) has not been decided as of the 3.14 and 3.15 cycles.

What this means in practice: on a free-threaded build, pure-Python threads do scale across cores for CPU-bound work. The cost is some single-threaded overhead (noticeable in 3.13, much reduced in 3.14) and the need for every C extension you use to declare free-threading support; packages that have not been updated cause the interpreter to re-enable the GIL at import time with a warning. You can check at runtime with sys._is_gil_enabled() (added in 3.13) and control the behaviour with the -X gil=0 flag or the PYTHON_GIL=0 environment variable on a free-threaded build.

Our advice for 2026: design for the standard build (asyncio for I/O, processes for CPU), treat free-threading as an opportunity to test on, and avoid relying on it in production until your entire dependency tree supports it.

Python gives you three concurrency models, each with a different cost model and a different sweet spot.

• threading — multiple OS threads inside one process, sharing memory. Switching is pre-emptive: the OS (and the GIL's switch interval, 5 ms by default) decides when a thread is paused, so shared data needs threading.Lock. Threads are cheap-ish (roughly 8 MB of reserved stack each, a few hundred are fine), work with any blocking library, and are the right choice for I/O-bound code that uses libraries without async support (for example requests, old database drivers, boto3).
• multiprocessing — multiple OS processes, each with its own interpreter and its own GIL. True parallelism for CPU-bound code. Processes are expensive to start (tens to hundreds of milliseconds, more on Windows and on macOS where the default start method is spawn), and data passed between them is pickled, so sending a 2 GB DataFrame to a worker is slow. Best for batch computation: image processing, simulation, data crunching.
• asyncio — a single thread running an event loop that switches between coroutines cooperatively, only at await points. Tasks are extremely cheap (a few KB each; tens of thousands are routine), there is no lock contention because only one coroutine runs at a time, and you always know where a switch can happen. The price: every library in the call chain must be async-aware, and one blocking call freezes everything.

Think of it as a table. Memory per unit: thread ≈ MB, process ≈ tens of MB, task ≈ KB. Parallel CPU: threads no (unless free-threaded), processes yes, asyncio no. Shared state: threads yes (with locks), processes no (use queues or shared memory), asyncio yes (safe between awaits). Works with blocking libraries: threads yes, processes yes, asyncio no (wrap them, see section 10).

The example below runs the same I/O simulation with all three models so you can see the API differences side by side.

An async def function is a coroutine function. Calling it does not run it — it returns a coroutine object, a paused computation that the event loop can drive. This surprises beginners: fetch() by itself does nothing and Python prints a RuntimeWarning: coroutine 'fetch' was never awaited. The coroutine runs only when something awaits it or wraps it in a Task.

await expr does two things: it pauses the current coroutine until expr (an awaitable: a coroutine, a Task or a Future) completes, and it hands control back to the event loop so other coroutines can run in the meantime. That hand-off is the only place a switch can occur. Between two awaits, your code runs without interruption — which is why asyncio needs far fewer locks than threading.

The event loop is a scheduler: a while True loop that keeps a queue of ready callbacks, runs them one by one, and uses the operating system's I/O multiplexing (epoll on Linux, kqueue on macOS, IOCP on Windows) to learn which sockets became readable or writable. When a coroutine awaits a socket read, the loop registers interest in that socket, runs other work, and resumes the coroutine when data arrives. You rarely touch the loop directly; asyncio.run() creates it, runs your main coroutine, and closes it.

Three related constructs complete the syntax: async with for asynchronous context managers (httpx.AsyncClient, database connections), async for for asynchronous iterators (streaming responses, async generators defined with yield inside async def), and async comprehensions such as [x async for x in agen()].

Mental model to remember: await is a *yield point*. If a function never awaits, it never yields, and it blocks the loop no matter how it is declared.

asyncio.run(coro) (Python 3.7+) is the standard entry point. It creates a fresh event loop, runs the coroutine until it returns, cancels any leftover tasks, shuts down async generators and the default executor, and closes the loop. Call it exactly once per program, from synchronous code, and never from inside a running coroutine (that raises RuntimeError: asyncio.run() cannot be called from a running event loop — the classic Jupyter error; notebooks already run a loop, so there you simply await main()). Python 3.11 added asyncio.Runner, a context manager that lets you run several coroutines on the same loop from sync code, which is handy in test harnesses.

Awaiting a coroutine runs it *inline* — the caller waits. To run something in the background while you continue, wrap it in a Task with asyncio.create_task(coro, name="..."). A Task is a Future subclass that schedules the coroutine on the loop immediately and lets you await its result later, cancel it, or add a done-callback. Always keep a reference to tasks you create (store them in a list or set); the loop holds only a weak reference, and a task that nobody references can be garbage-collected mid-flight.

Useful introspection: asyncio.current_task(), asyncio.all_tasks(), task.get_name(), task.done(), task.cancelled(). Python 3.12 added asyncio.eager_task_factory, which starts a task synchronously up to its first await and can cut overhead for tasks that often finish without suspending. Python 3.14 added command-line tools, python -m asyncio ps <PID> and python -m asyncio pstree <PID>, that print the live task tree of another running process — enormously helpful when a production server appears to hang.

Keep the entry point tidy: one async def main(), one asyncio.run(main()) inside if __name__ == "__main__":.

Two APIs run several coroutines at once and collect their results. They differ in how they handle failure, which is exactly what matters in production.

asyncio.gather(*aws, return_exceptions=False) schedules every awaitable as a task and returns a list of results in the same order as the inputs. If one raises, gather propagates that first exception immediately — but the other tasks keep running in the background, unobserved. You often do not want that: a failed payment check should cancel the fraud check running alongside it. With return_exceptions=True, exceptions are returned in the result list instead of raised, so you can process partial success — useful for "fetch 50 product pages and report which ones failed".

asyncio.TaskGroup (Python 3.11+) is the modern, structured alternative. You open it with async with asyncio.TaskGroup() as tg:, create tasks with tg.create_task(coro), and when the block exits it waits for all of them. If any task fails, the group cancels all remaining tasks, waits for them to finish cancelling, and then raises an ExceptionGroup containing every exception that occurred. You handle it with the except* syntax (also 3.11+). This is structured concurrency: tasks cannot outlive the block that created them, so nothing leaks and nothing runs unobserved.

Rule of thumb: use TaskGroup as the default for new code. Use gather(..., return_exceptions=True) when you deliberately want *every* task to run to completion regardless of failures and then inspect results. For the "first to finish wins" pattern, look at asyncio.wait(..., return_when=FIRST_COMPLETED) or asyncio.as_completed(), which yields results as they arrive rather than in input order.

The example shows the behavioural difference with one task that fails.

A network call that never returns is worse than one that fails fast, because it silently holds a worker, a database connection and a user's patience. Every external await in production code should have a timeout.

asyncio.timeout(seconds) (Python 3.11+) is the preferred tool: an async context manager that cancels whatever is running inside the block when the deadline passes and converts the resulting CancelledError into a TimeoutError (since 3.11 asyncio.TimeoutError is an alias of the built-in TimeoutError). It can wrap several awaits at once, you can reschedule it with .reschedule(), and there is a sibling asyncio.timeout_at(deadline) for absolute deadlines. The older asyncio.wait_for(aw, timeout) still works and is fine for a single awaitable, but the context-manager form composes better.

Cancellation is how timeouts, TaskGroup failures and Ctrl+C are all implemented. Calling task.cancel() arranges for asyncio.CancelledError to be raised *inside* the task at its next await. The task then unwinds: finally blocks run, async with exits, and the exception propagates out. Three rules keep you safe:

1. Never swallow CancelledError. If you catch it to clean up, re-raise it. A bare except Exception does not catch it (since 3.8 it derives from BaseException), which is deliberate.
2. Do cleanup in finally — closing files, releasing locks, rolling back transactions.
3. If cleanup itself needs to await (for example sending a "goodbye" message), wrap it in asyncio.shield() or a fresh asyncio.timeout(); otherwise a second cancel could interrupt your cleanup.

asyncio.shield(aw) protects an inner awaitable from cancellation of the outer task — use it sparingly, for writes that must complete once started (a payment capture, an audit record).

The most common reason to reach for asyncio is talking to HTTP APIs. The requests library is blocking and must not be awaited; the modern choice is httpx, which offers a requests-like API with both sync and async clients, HTTP/2 support and proper timeouts. Install it with uv add httpx or pip install httpx.

The pattern is always: create one httpx.AsyncClient per application (or per batch), reuse it for every request, and close it with async with. The client holds a connection pool, so reusing it avoids a new TCP and TLS handshake for every call — on a Mumbai-to-Singapore route that handshake alone is 100–150 ms. Creating a client per request is the number one httpx performance mistake.

Key client options: base_url (so you call client.get("/users")), timeout=httpx.Timeout(10.0, connect=3.0) (always set one; the default is 5 seconds), headers for auth tokens, limits=httpx.Limits(max_connections=50), and transport for retries or mocking. Call response.raise_for_status() to turn 4xx/5xx into exceptions, then response.json().

Rate limiting with asyncio.Semaphore. Firing 5,000 requests at once will get you throttled or banned. An asyncio.Semaphore(20) allows at most 20 coroutines inside its async with block at a time; the rest wait at the gate. Combine it with a TaskGroup and a timeout and you have a production-grade fetcher in twenty lines. For strict requests-per-second limits, add a small await asyncio.sleep() after acquiring the semaphore or use a token-bucket library such as aiolimiter.

The example fetches the first page of several public GitHub repositories concurrently, capped at 5 in flight, with a per-request timeout and error isolation so one failure does not sink the batch.

Real projects are never 100% async. You will have a legacy requests call, a synchronous ORM query, a boto3 upload, a PDF generator, or a CPU-heavy transform — and all of them block the event loop if called directly inside a coroutine. Blocking the loop for even 200 ms means every other request on your FastAPI server stalls for 200 ms. In a server handling 500 requests per second, one blocked second is 500 angry users.

The fix is to push blocking work to another thread or process and await its completion:

• asyncio.to_thread(func, *args, **kwargs) (Python 3.9+) runs func in the loop's default ThreadPoolExecutor and returns an awaitable. This is the right tool for blocking I/O (network, disk, sync database drivers) because the GIL is released while those wait. It is the simplest and should be your default.
• loop.run_in_executor(executor, func, *args) is the lower-level form. Pass None for the default thread pool or your own executor. Crucially, you can pass a ProcessPoolExecutor, which is how you run CPU-bound work (image resizing, report generation, ML inference) without blocking the loop *and* without the GIL limiting you. Note that it takes positional args only — use functools.partial for keyword arguments.

The reverse bridge also exists: from a thread that is *not* running the loop, schedule a coroutine onto the loop with asyncio.run_coroutine_threadsafe(coro, loop), and call plain functions on the loop with loop.call_soon_threadsafe(). All other asyncio objects (Queue, Event, Future) are not thread-safe and must only be touched from the loop's thread.

How do you find hidden blocking calls? Run with PYTHONASYNCIODEBUG=1 or asyncio.run(main(), debug=True): asyncio then logs every callback that takes longer than 100 ms (loop.slow_callback_duration).

concurrent.futures is the high-level, synchronous-world API for running callables in a pool of workers. It is what you use when your program is *not* built on asyncio — a CLI tool, a Django view, a data script — but still needs concurrency. All executors share one interface: submit(fn, *args) returns a Future, map(fn, iterable) returns results in order, and with Executor() as pool: waits for everything on exit (shutdown(wait=True)).

• ThreadPoolExecutor(max_workers=None) — threads; default worker count is min(32, os.cpu_count() + 4). Use for I/O-bound tasks with blocking libraries.
• ProcessPoolExecutor(max_workers=None) — processes; default is os.cpu_count(). Use for CPU-bound tasks. The callable and its arguments must be picklable (top-level functions, not lambdas or closures), and your script needs the if __name__ == "__main__": guard because child processes re-import the main module under the spawn start method (default on Windows and macOS, and the default on Linux as well from Python 3.14).
• InterpreterPoolExecutor (new in Python 3.14, PEP 734) — runs callables in a pool of subinterpreters, each with its own GIL, inside one process. It gives CPU parallelism like processes but with cheaper start-up and no OS process overhead. Objects crossing the boundary are still copied (pickled), and C extensions must support multiple interpreters, so treat it as a promising middle ground to experiment with rather than a drop-in replacement today.

Working with Futures. future.result(timeout=...) blocks until done; future.exception() returns the raised exception; as_completed(futures) yields futures as they finish, perfect for progress bars; wait(futures, return_when=FIRST_EXCEPTION) offers finer control. Python 3.14 also added a buffersize parameter to Executor.map() so a huge input iterable is consumed lazily instead of being submitted all at once.

A practical sizing note: for I/O-bound thread pools, 10–50 workers is typical; for CPU-bound process pools, never exceed the number of physical cores.

Here is the decision procedure experienced Python engineers apply, in order:

1. Is it CPU-bound? (CPU time ≈ wall time.) Use ProcessPoolExecutor or multiprocessing. Consider NumPy/pandas vectorisation first — a vectorised operation is often 50× faster than any parallel pure-Python loop, and many NumPy operations release the GIL so plain threads also help. On a free-threaded 3.14 build with compatible dependencies, threads become an option; InterpreterPoolExecutor is worth benchmarking.
2. Is it I/O-bound and are async libraries available for everything in the hot path (httpx, asyncpg, aiosqlite, aiofiles, aiokafka, motor, redis.asyncio)? Use asyncio. It scales to tens of thousands of concurrent connections with minimal memory, and frameworks like FastAPI, Starlette, aiohttp and Litestar are built on it.
3. Is it I/O-bound but stuck with blocking libraries (requests, psycopg2 sync mode, boto3, legacy SDKs)? Use ThreadPoolExecutor, or asyncio with asyncio.to_thread if the rest of the app is async. Threads are also the pragmatic choice for small scripts where asyncio's "everything must be async" requirement is more trouble than it is worth.
4. Mixed workload (an API that fetches data, then crunches it)? asyncio for the I/O, with CPU parts offloaded through run_in_executor(ProcessPoolExecutor). This is the standard architecture for ML inference services.
5. Do you need concurrency at all? Ten sequential database queries of 2 ms each cost 20 ms. Adding asyncio complexity to save 18 ms is not worth it. Measure first.

Two more factors: debuggability (sequential code is easiest, asyncio next because switches are explicit, threads hardest because of races) and deployment (process pools multiply memory usage; a 500 MB model loaded in 8 workers needs 4 GB — look at shared memory or a single worker with async batching).

The snippet below is a tiny self-check you can paste into any project to classify a function and suggest a model.

1. FastAPI and ASGI web services. FastAPI runs on an asyncio event loop (via Uvicorn). An async def endpoint that awaits httpx, asyncpg or redis.asyncio can serve thousands of concurrent requests on one worker. FastAPI runs plain def endpoints in a thread pool automatically — so a sync endpoint is safe, but an async def endpoint that calls requests.get blocks the whole server. This single rule explains most "FastAPI is slow" complaints.

2. Aggregator and BFF (backend-for-frontend) services. A travel app's search page calls flight, hotel and cab providers. With TaskGroup and per-provider timeouts, the page returns in the time of the slowest provider (capped at, say, 2 seconds), not the sum of all of them, and a failing provider is reported as "unavailable" rather than breaking the page.

3. Web scraping and bulk API ingestion. Pulling 200,000 product listings or GST invoices from an API with a semaphore of 20–50 concurrent requests, retries with exponential backoff and a rate limiter. Async turns a 6-hour sequential job into 15 minutes without extra machines.

4. Data pipelines and ETL. Extract concurrently with asyncio or threads, transform with pandas in a ProcessPoolExecutor (one process per CSV partition), load with async database drivers. Airflow and Prefect tasks commonly use exactly this split.

5. Chatbots, WebSockets and streaming LLM responses. async for chunk in stream: over a WebSocket or SSE connection, where one process holds 10,000 open sockets — impossible with a thread per connection.

6. Background workers and queues. An asyncio.Queue with N consumer tasks implements a producer–consumer pipeline (notification sending, webhook delivery). Python 3.13 added Queue.shutdown() and QueueShutDown for clean termination of consumers.

7. Test suites. pytest-asyncio or anyio run async tests; httpx.ASGITransport lets you test a FastAPI app in-process with no network at all.

The example sketches a FastAPI aggregator endpoint with timeouts and graceful degradation — the pattern behind many real search pages.

1. Blocking the event loop. Calling time.sleep, requests.get, a sync DB driver, or a heavy loop inside async def. Symptom: everything else stalls; with debug mode on, asyncio logs "Executing <Task> took 2.3 seconds". Fix: use the async equivalent (asyncio.sleep, httpx), or offload with asyncio.to_thread / run_in_executor.

2. Forgetting to await. fetch_user() instead of await fetch_user() returns a coroutine object that never runs, and you get RuntimeWarning: coroutine was never awaited. Type checkers (mypy, pyright) flag this; enable them.

3. Awaiting sequentially when you meant concurrently. a = await f(); b = await g() runs f then g. Fix: a, b = await asyncio.gather(f(), g()) or a TaskGroup.

4. Creating a task and dropping the reference. asyncio.create_task(job()) with no variable can be garbage-collected mid-run. Fix: keep tasks in a set and discard on completion, or use a TaskGroup.

5. Swallowing CancelledError. except Exception does not catch it, but except BaseException and bare except: do — and then timeouts and shutdown silently break. Fix: re-raise, and clean up in finally.

6. One httpx client per request. Loses connection pooling and may exhaust sockets (TIME_WAIT pile-up). Fix: one client per app, created in the lifespan / startup hook.

7. Unbounded concurrency. gather(*[fetch(u) for u in 50_000_urls]) opens 50,000 connections and gets you rate-limited or OOM-killed. Fix: asyncio.Semaphore, a bounded asyncio.Queue, or batch the input.

8. Using threads for CPU-bound work on the default build. No speedup because of the GIL. Fix: ProcessPoolExecutor, vectorisation, or a free-threaded build after verifying your dependencies.

9. Missing the if __name__ == "__main__": guard with processes. Under spawn, children re-import the main module and start their own pools — a fork bomb on Windows/macOS, and on Linux since 3.14. Fix: always guard the entry point.

10. Sharing asyncio objects across threads. asyncio.Queue, Event and Future are not thread-safe. Fix: loop.call_soon_threadsafe or asyncio.run_coroutine_threadsafe from the other thread, or use queue.Queue with to_thread.

11. Calling asyncio.run() inside a running loop. Common in Jupyter and inside frameworks. Fix: just await the coroutine; in sync-only libraries, accept a loop or use asyncio.Runner.

12. No timeouts anywhere. A hung upstream holds every worker forever. Fix: asyncio.timeout() around every external await and httpx.Timeout on the client.

What is the difference between concurrency and parallelism in Python?

Concurrency is managing many tasks in overlapping time on possibly one core — asyncio and (on the default build) threads do this. Parallelism is executing tasks at the same instant on multiple cores — multiprocessing, ProcessPoolExecutor, and threads on a free-threaded build do this. Concurrency speeds up I/O-bound work; parallelism speeds up CPU-bound work.

Is the GIL removed in Python 3.13 or 3.14?

Not from the default build. Python 3.13 introduced an optional, experimental free-threaded build without the GIL (PEP 703). Python 3.14 promoted that build to officially supported (PEP 779) but it remains a separate download, and the standard python you install still has the GIL. Whether free-threading ever becomes the default is undecided.

When should I use asyncio instead of threads in Python?

Use asyncio when the work is I/O-bound, you need many concurrent connections (hundreds to tens of thousands), and async libraries exist for your dependencies — typical for web services, scrapers and API clients. Use threads when the work is I/O-bound but your libraries are blocking, or for small scripts where asyncio adds more ceremony than value.

Does asyncio make my code faster?

Only when the code spends time waiting. Asyncio removes idle time; it does not add CPU. A CPU-bound loop inside asyncio is exactly as slow as outside it, and actually blocks every other task while it runs.

What is the difference between asyncio.gather and asyncio.TaskGroup?

gather returns results in input order and, on failure, raises the first exception while leaving the other tasks running (unless you pass return_exceptions=True). TaskGroup (3.11+) cancels all sibling tasks on the first failure and raises an ExceptionGroup — structured concurrency with no leaked tasks. Prefer TaskGroup for new code.

Can I use the requests library with asyncio?

Not directly — requests is blocking and would freeze the event loop. Either switch to httpx.AsyncClient (near-identical API) or wrap the call with await asyncio.to_thread(requests.get, url).

How many threads or processes should I use in Python?

For I/O-bound thread pools, 10–50 workers is a sensible range; the default ThreadPoolExecutor size is min(32, cpu_count + 4). For CPU-bound process pools, use at most the number of physical cores (os.cpu_count(), or os.process_cpu_count() on 3.13+ to respect container limits). For asyncio, bound in-flight work with a Semaphore sized to what the upstream service tolerates, often 10–100.

How do I add a timeout to an async function in Python?

Wrap the await in async with asyncio.timeout(seconds): (Python 3.11+) and catch TimeoutError. For a single awaitable on older versions, await asyncio.wait_for(coro, timeout=seconds) works the same way.

Q1. What is the GIL and why does CPython have it?

The Global Interpreter Lock is a mutex that lets only one thread run Python bytecode at a time. CPython uses reference counting for memory management, and the GIL protects those counts (and other interpreter state) from concurrent modification cheaply. It keeps single-threaded performance high and C extensions simple, at the cost of CPU-bound threads not running in parallel. It is released during blocking I/O and by many C extensions, which is why threads still help I/O-bound code.

Q2. What happens when you call an async function without await?

You get a coroutine object; the body does not execute. When that object is garbage-collected, Python emits RuntimeWarning: coroutine '...' was never awaited. The coroutine runs only when awaited, wrapped in a Task via asyncio.create_task, or passed to asyncio.run.

Q3. Explain how the asyncio event loop works internally.

It is a single-threaded scheduler. It keeps a ready queue of callbacks and a heap of timed callbacks, and on each iteration it asks the OS selector (epoll/kqueue/IOCP) which file descriptors are ready, with a timeout equal to the next scheduled timer. It then runs ready callbacks, each of which typically resumes a coroutine until its next await. Because switching happens only at awaits, the loop never pre-empts running code.

Q4. Compare asyncio.gather, asyncio.wait and asyncio.as_completed.

gather awaits all and returns ordered results (optionally collecting exceptions). wait returns (done, pending) sets and supports return_when=FIRST_COMPLETED / FIRST_EXCEPTION / ALL_COMPLETED, giving you manual control. as_completed yields awaitables in completion order so you can process results as they arrive. TaskGroup is the structured, cancel-on-failure alternative to gather.

Q5. How does cancellation work in asyncio and what are the rules for handling CancelledError?

task.cancel() schedules a CancelledError to be thrown into the coroutine at its next await. It derives from BaseException so except Exception does not catch it. If you catch it, re-raise after cleanup; put cleanup in finally; use asyncio.shield for operations that must complete once started; never block during cleanup.

Q6. How would you run CPU-bound work from an async web server without blocking it?

Use loop.run_in_executor with a ProcessPoolExecutor (created once at startup), awaiting the returned future. Threads would still be limited by the GIL on the default build. Keep the executor's worker count at or below the number of cores, and make arguments and return values picklable and small.

Q7. Why is the if __name__ == "__main__" guard required with multiprocessing?

With the spawn start method (default on Windows and macOS, and on Linux from Python 3.14), each child process starts a fresh interpreter and re-imports the main module to find the target function. Without the guard, the module-level code that creates the pool runs again in every child, recursively spawning processes until the system runs out of resources.

Q8. What is structured concurrency and how does TaskGroup implement it?

Structured concurrency means a concurrent task's lifetime is bounded by a lexical scope: it cannot outlive the block that created it. TaskGroup enforces this: the async with block does not exit until every task finishes, a failure cancels the siblings, and all errors surface together in an ExceptionGroup handled with except*. This eliminates leaked background tasks and unobserved exceptions.

Q9. Threads in Python are 'useless' because of the GIL — true or false?

False. Threads are excellent for I/O-bound work because the GIL is released while waiting on sockets, files and sleeps; many C extensions (NumPy, hashlib, zlib, image libraries) release it during heavy computation too. They are a poor fit only for pure-Python CPU-bound loops on the default build. On free-threaded builds (supported since 3.14) even that limitation goes away, subject to extension compatibility.

Q10. What is the difference between asyncio.Semaphore and asyncio.Lock, and when would you use each?

A Lock allows exactly one holder — use it to protect a critical section such as refreshing an auth token so that ten concurrent requests do not all refresh it. A Semaphore(n) allows up to n holders — use it to bound concurrency, for example at most 20 simultaneous HTTP requests to one upstream. Both are async context managers and neither is thread-safe; they only coordinate coroutines on the same loop.

Build a small but production-shaped tool that watches the prices of several products across e-commerce APIs, exactly the kind of service a price-comparison startup runs every few minutes. Requirements:

1. Fetch each product's price from each store concurrently, with at most 4 requests in flight (semaphore) and a 1.5 second per-request timeout.
2. Use a single shared httpx.AsyncClient. One store is slow and one endpoint is broken — the run must still finish and report those as errors, not crash.
3. Use asyncio.TaskGroup and collect results into a list of PriceResult dataclasses.
4. After fetching, compute a CPU-heavy "deal score" for each product in a ProcessPoolExecutor via run_in_executor, so the event loop stays responsive (a heartbeat task proves it).
5. Print a report: cheapest store per product, the deal score, and a list of failures. Print total wall time.

To keep the exercise runnable offline and deterministic, the program uses httpx.MockTransport, which lets a function answer requests in-process without any network. Replace the transport with a real one (delete the transport= argument and point STORES at real URLs) to run it against live APIs — nothing else changes, which is the point of the design. Install httpx with uv add httpx or pip install httpx, then run python price_monitor.py.

Stretch goals once it works: add retry with exponential backoff for TransportError; replace the mock with the public https://dummyjson.com/products/{id} API; add a bounded asyncio.Queue so a producer discovers products while consumers fetch prices; write a pytest-asyncio test that asserts the slow store is reported as a timeout.

• Concurrency overlaps waiting; parallelism uses multiple cores. I/O-bound work needs concurrency; CPU-bound work needs parallelism.
• The GIL lets one thread run Python bytecode at a time but is released during I/O and in many C extensions. Free-threaded builds were experimental in 3.13 and are officially supported but still optional in 3.14 (PEP 779); the default interpreter keeps the GIL.
• threading suits I/O with blocking libraries; multiprocessing / ProcessPoolExecutor suits CPU-bound work (picklable functions, __main__ guard); asyncio suits high-concurrency I/O with async libraries.
• async def creates coroutines; await is the only switch point; the event loop drives everything; asyncio.run() is the single entry point.
• asyncio.create_task runs work in the background — keep references. asyncio.gather collects ordered results; asyncio.TaskGroup (3.11+) gives structured concurrency with cancel-on-failure and except*.
• Always set timeouts (asyncio.timeout, httpx.Timeout). Never swallow CancelledError; clean up in finally; shield only what must complete.
• Use httpx.AsyncClient with one shared client, raise_for_status(), and an asyncio.Semaphore to bound concurrency.
• Bridge blocking code with asyncio.to_thread (I/O) and run_in_executor(ProcessPoolExecutor) (CPU). concurrent.futures gives the same pools to sync code, plus InterpreterPoolExecutor in Python 3.14.
• Measure CPU time vs wall time before choosing a model, and skip concurrency entirely when the gain is milliseconds.

Next lecture: Testing with pytest