Python 3.13 Async Patterns 2026: asyncio, Trio, AnyIO & Free-Threaded GIL Removal

Q: Should I use asyncio.gather or asyncio.TaskGroup in 2026?

Use TaskGroup when you want structured concurrency: sibling tasks are tied to the surrounding scope, and failure/cancellation behavior is easier to reason about. Use gather when you intentionally want to await a known collection of awaitables and handle partial results or exceptions yourself. A safe migration starts with replacing untracked create_task calls, then reviewing gather sites one by one.

Q: asyncio vs Trio vs AnyIO — which to use in 2026?

Three frameworks, three philosophies: ASYNCIO is the standard library, TaskGroup-based, mature in 3.13, broadest ecosystem (FastAPI, aiohttp, asyncpg, all major HTTP and DB libraries). Default for new projects unless you have specific reasons to deviate. TRIO is the structured-concurrency reference implementation. Cleaner cancellation semantics, no implicit task spawning, nurseries are the only concurrency primitive. Strongest correctness guarantees but smaller ecosystem (you do not get FastAPI directly). Best for safety-critical code or when you want airtight reasoning about task lifetime. ANYIO is the unification layer: write code once using AnyIO primitives, run on either asyncio or trio. Used by httpx, FastAPI internals, AsyncSQLModel. If you ship a library, you should target AnyIO for portability. If you ship an application, pick asyncio (broadest tooling) or trio (strongest correctness) and commit. The 2026 trend: asyncio absorbed Trio ideas (TaskGroup is essentially nurseries), so the gap is narrowing. AnyIO 4.0+ now supports asyncio as a first-class backend with feature parity for cancellation, timeouts, and exception groups.

Q: How does the Python 3.13 JIT compiler (PEP 744) affect async code?

PEP 744 documents CPython copy-and-patch JIT work. For async services, treat the JIT as a workload-specific measurement topic. Benchmark startup, warmup, event-loop dispatch, CPU-heavy handlers, memory use, observability, and deployment support before changing a production runtime build.

Q: What are the most common asyncio bugs in 2026?

Top 10 production bugs we still see: (1) FORGETTING TO AWAIT — `coroutine` object created but never scheduled. Fix: enable `PYTHONASYNCIODEBUG=1` in dev. (2) BLOCKING THE EVENT LOOP with sync I/O (open a file, requests.get, time.sleep). Fix: use `asyncio.to_thread` or aiohttp/aiofiles. (3) UNHANDLED TASK EXCEPTIONS — `asyncio.create_task(coro)` without storing the task or awaiting it; exception logged as "Task exception was never retrieved" but service runs degraded. Fix: use TaskGroup. (4) CANCELLATION NOT PROPAGATING — catching `CancelledError` and not re-raising. Fix: never silently catch CancelledError. (5) DEADLOCK ON SAME LOOP — calling `loop.run_until_complete` from inside an already-running loop. Fix: use `asyncio.run` only at top level. (6) CONNECTION POOL EXHAUSTION — async DB pools default to small sizes (asyncpg 10, aiomysql 10). Fix: tune `max_size` for traffic. (7) UNCLOSED RESOURCES on shutdown — clients/sessions not in `async with`. Fix: use context managers everywhere. (8) GATHER WITH MIXED EXCEPTIONS — first exception masks others. Fix: TaskGroup gives ExceptionGroup. (9) AWAIT IN __init__ — constructors cannot be async. Fix: use async classmethod factory. (10) RACE ON SHARED STATE — multiple tasks mutating same dict. Fix: asyncio.Lock or single-writer pattern.

Q: How do I cancel an asyncio task safely?

Cancellation in 2026 follows three principles: (1) CANCELLATION IS COOPERATIVE — `task.cancel()` schedules `CancelledError` to be raised at the next `await`; the task can choose to handle it. (2) CANCELLATION SHOULD ALWAYS PROPAGATE — never `try: ... except CancelledError: pass` without re-raising. The standard pattern: `try: await something() except asyncio.CancelledError: cleanup(); raise`. (3) USE `asyncio.shield` SPARINGLY — shield prevents cancellation, useful for "must complete" cleanups but easy to misuse. SAFE PATTERNS: (a) `asyncio.timeout(5)` context manager (3.11+) — cleaner than `wait_for`, supports nesting. (b) TaskGroup automatically cancels siblings on first failure. (c) For "graceful shutdown" of long-running tasks: signal handler sets an asyncio.Event, task awaits the event between work units. ANTI-PATTERNS: don't loop on `task.cancel(); task.cancel()` hoping it eventually wins — task may be in shielded section. Use `await asyncio.wait_for(task, timeout=5)` instead — it cancels and waits. The new `Task.uncancel()` (3.11+) is for advanced cases where you need to suppress one cancel but allow future cancels — used internally by TaskGroup.

Q: Can I mix asyncio with threads or processes?

Yes — three patterns, in order of preference for I/O-bound code: (1) `asyncio.to_thread(blocking_func, *args)` — runs blocking_func in a thread from the default executor. Returns an awaitable. Best for occasional blocking calls (legacy library, file I/O without aiofiles). Caveat: default thread pool is min(32, cpu+4) workers. (2) `loop.run_in_executor(executor, func, *args)` — same idea, custom executor. Use for CPU-bound work via ProcessPoolExecutor. (3) `asyncio.run_coroutine_threadsafe(coro, loop)` — schedules a coroutine on a different thread's event loop. Useful in hybrid sync/async code or callbacks from sync libraries. ANTI-PATTERNS: (a) Calling `asyncio.run()` from a thread that already has a running loop — RuntimeError. (b) Awaiting a `Future` returned by `run_coroutine_threadsafe` directly — it is a concurrent.futures.Future, not asyncio.Future. Use `asyncio.wrap_future` or `.result()`. (c) Sharing mutable state between threads and async tasks without locks — use `asyncio.Lock` for async-only, `threading.Lock` wrapped in `to_thread` for cross-boundary. The 3.13 free-threaded build changes this calculus — true thread parallelism becomes practical for CPU work, reducing need for ProcessPoolExecutor.

Python async decisions in 2026 come down to lifecycle control, cancellation behavior, library portability, and whether CPU-bound work belongs inside the event-loop process at all. This guide compares asyncio TaskGroup, gather, Trio, AnyIO, free-threaded CPython evaluation, and JIT measurement without assuming that one runtime wins every workload.

Source-reviewed update - May 22, 2026

Python Async Source Review

This refresh replaces unsupported universal benchmark claims with source-backed guidance and a reproducible measurement checklist for Python async services.

Decision checks

- Use TaskGroup when sibling task lifetime should be scoped and cancellation should compose.
- Keep gather when partial results or exception collection are the intended semantics.
- Evaluate free-threaded CPython with your extensions, deploy target, CPU profile, and memory budget.
- Benchmark JIT builds with startup, warmup, steady-state, and observability included.

Primary docs

Python asyncio documentation Python TaskGroup documentation PEP 703 optional GIL PEP 654 exception groups PEP 744 JIT compilation Trio documentation AnyIO documentation

Use next on Bytepane

Python vs Go vs Rust decision guide Node streams backpressure guide REST vs GraphQL decision guide

Quick Decision Matrix — 2026

Use Case	Recommended	Why
Web service (FastAPI, aiohttp)	asyncio + TaskGroup	Broadest ecosystem; TaskGroup gives structured concurrency.
CPU-bound parallel computation	3.13t free-threaded + ThreadPoolExecutor	True parallelism without process overhead.
Library that should run on either backend	AnyIO	Portable across asyncio and Trio; httpx and FastAPI use this.
Safety-critical / correctness-first	Trio	Strongest cancellation semantics; nurseries enforce structured concurrency.
Mixed sync/async legacy	asyncio + to_thread	Bridge to blocking libraries without rewriting.
Tight numeric loops on single thread	3.13 GIL build + JIT enabled	JIT warmup pays off; no-GIL adds 10 percent overhead for nothing.

How To Measure TaskGroup vs gather vs Trio

Pattern	What to measure	Failure behavior to verify	Good fit
asyncio.gather	Batch latency, exception collection, partial-result handling, and whether task references are retained.	Confirm exactly what happens when one awaitable raises and whether remaining work should continue.	Known finite batches where you intentionally manage all result and error states.
asyncio.TaskGroup	Cancellation latency, sibling cleanup, ExceptionGroup handling, and shutdown determinism.	Confirm sibling tasks cancel and clean up when one task fails.	Request-scoped or job-scoped child tasks that should not outlive the parent scope.
trio.open_nursery	Scheduler behavior, cancellation scope behavior, library ecosystem fit, and service framework support.	Confirm nursery lifetime and cancellation semantics match the application architecture.	Correctness-first services where Trio-compatible libraries are available.
anyio.create_task_group	Backend parity, cancellation behavior across asyncio/Trio, and dependency compatibility.	Run the same failure tests on each backend you intend to support.	Libraries and apps that want structured concurrency while preserving backend flexibility.

Use this as a measurement plan, not a universal timing chart. Hardware, event-loop policy, client library, network path, workload shape, and exception rate change the answer.

Free-Threaded Python Evaluation Checklist

PEP 703 matters most when CPU-bound threaded code is a realistic part of the architecture. For I/O-bound async services, the event loop is still cooperative, so the right question is usually whether blocking CPU work should move to a worker pool, a separate service, or a free-threaded runtime build.

Check	Why it matters	Decision signal
Extension compatibility	Native wheels and C extensions can determine whether the build is viable at all.	All production dependencies install, test, and profile cleanly on the target build.
Single-thread overhead	Threading wins can be offset if baseline request handling slows down.	Median and p95 request latency remain inside budget before parallel work is added.
CPU-bound scaling	The build is only useful if real threaded work scales under your lock/contention pattern.	Throughput improves on representative jobs without increasing tail latency elsewhere.
Memory and deployment	Runtime support, container images, platform constraints, and memory overhead affect operations.	The deployment path is repeatable and rollback is simple.

JIT Compiler Measurement Checklist

Workload	Measure	Interpretation
Short-lived CLI or serverless task	Startup and warmup time.	A slower cold path can erase steady-state gains.
Long-running async API	Request latency, handler CPU time, event-loop delay, memory, and error rate.	Keep the JIT only if it improves the actual hot path under production-like traffic.
CPU-heavy pure Python code	Steady-state throughput after warmup, plus profiling visibility.	JIT gains are workload-specific; compare against vectorized/native alternatives too.
Observability-sensitive service	Profilers, stack traces, coverage, tracing, and incident debugging.	Runtime speed is not worth losing operational clarity.

Cancellation Patterns Cheat Sheet

Goal	3.13 Pattern	Pre-3.11 Equivalent
Cancel after timeout	async with asyncio.timeout(5):	await asyncio.wait_for(coro, 5)
Group of tasks, all-or-nothing	async with TaskGroup() as tg:	await asyncio.gather(*tasks)
Protect critical cleanup	await asyncio.shield(cleanup())	same
Cancel and wait for cleanup	task.cancel(); await task	same
Suppress one cancellation	task.uncancel()	N/A (3.11+)
Race two coros, cancel loser	asyncio.wait(FIRST_COMPLETED)	same
Background task tied to scope	tg.create_task(coro)	asyncio.create_task (not safe)

Frequently Asked Questions

Should I use asyncio.gather or asyncio.TaskGroup in 2026?

Use TaskGroup when child tasks should be scoped to a parent block and sibling cancellation should be automatic. Keep gather when you intentionally want to await a known batch and handle partial results or exceptions yourself. The practical migration is not "replace every gather"; it is "remove untracked create_task calls first, then review gather sites by failure semantics."

What is the Python 3.13 free-threaded build (PEP 703)?

PEP 703 makes the Global Interpreter Lock optional in CPython builds. It can matter for CPU-bound threaded code, but it does not automatically make async I/O faster. Before adopting it, test dependency wheels, extension compatibility, single-thread request latency, multi-thread scaling, memory behavior, and rollback on your deployment platform.

asyncio vs Trio vs AnyIO — which to use in 2026?

asyncio is the standard library, TaskGroup-based, mature in 3.13, broadest ecosystem (FastAPI, aiohttp, asyncpg, all major HTTP and DB libraries). Default for new projects. Trio is the structured-concurrency reference implementation with cleanest cancellation semantics but smaller ecosystem. AnyIO is the unification layer: write code once using AnyIO primitives, run on either asyncio or trio. If you ship a library, target AnyIO for portability. If you ship an application, pick asyncio (broadest tooling) or Trio (strongest correctness).

How does the Python 3.13 JIT compiler (PEP 744) affect async code?

PEP 744 documents CPython's copy-and-patch JIT work. For async services, benchmark it like any runtime change: startup, warmup, steady-state handler CPU, event-loop delay, memory, profiling, tracing, and deployment support. Treat universal speedup claims skeptically until your own traffic shape proves them.

What are the most common asyncio bugs in 2026?

Top 5: forgetting to await (coroutine never scheduled), blocking the event loop with sync I/O, unhandled task exceptions from bare create_task, cancellation not propagating (silently catching CancelledError), and connection pool exhaustion under load. Enable PYTHONASYNCIODEBUG=1 in development to catch the first three. Use TaskGroup to fix the third. Never silently catch CancelledError — always re-raise.

How do I cancel an asyncio task safely?

Cancellation is cooperative: task.cancel() schedules CancelledError to be raised at the next await; the task can choose to handle it. Cancellation should always propagate — never silently catch CancelledError without re-raising. Use asyncio.shield sparingly. The standard cleanup pattern: try await something() except CancelledError: cleanup(); raise. asyncio.timeout(5) context manager (3.11+) is cleaner than wait_for.

What is structured concurrency and why does it matter?

Structured concurrency: every concurrent task has a clearly bounded lifetime defined by an enclosing scope. When the scope exits, all tasks are guaranteed to have completed or been cancelled. The opposite is "unstructured" concurrency where you spawn a task and forget it — leading to leaks, lost errors, undefined shutdown order. Trio popularized this with nurseries; asyncio adopted it as TaskGroup. Errors are never lost, resource cleanup is deterministic, and cancellation composes.

Can I mix asyncio with threads or processes?

Yes — three patterns: asyncio.to_thread(blocking_func) runs blocking_func in a thread from the default executor (best for occasional blocking calls). loop.run_in_executor lets you use a ProcessPoolExecutor for CPU-bound work. asyncio.run_coroutine_threadsafe schedules a coroutine on a different thread\'s event loop. Anti-patterns: calling asyncio.run() from a thread that already has a running loop (RuntimeError); awaiting a Future returned by run_coroutine_threadsafe directly.