What distinguishes an asyncio.Task from a plain asyncio.Future?

### The class relationship `issubclass(asyncio.Task, asyncio.Future)` is `True`, and that single fact organises the whole answer. Everything a Future can do, a Task can do; a Task adds one capability — it drives a coroutine. ### What a Future is An `asyncio.Future` is a one-shot result slot with three states: pending, finished (with a result or an exception), or cancelled. Its surface is small: * `set_result(value)` / `set_exception(exc)` — fill the slot. Calling either twice, or calling them on a finished future, raises `asyncio.InvalidStateError`. * `result()` / `exception()` — read the outcome; `result()` re-raises a stored exception, and both raise `InvalidStateError` if the future is not done. * `done()`, `cancelled()`, `cancel()`, `add_done_callback(fn)`. * `__await__` — awaiting a pending future suspends the awaiting coroutine and registers it to be woken when the slot is filled. Crucially there is **no code inside a Future**. It will stay pending forever unless some other party fills it. That other party is usually a callback: a protocol receiving bytes, a signal handler, a timer, or an adapter around a callback-based library. This is the Future's real job in asyncio — it is the seam between the callback world and the `await` world. ```python future = asyncio.get_running_loop().create_future() start_legacy_fetch(future.set_result) # callback fills the slot value = await future # await world sees a plain value ``` Futures are bound to one event loop and are **not thread-safe**; touching one from another thread is a bug, and asyncio provides a dedicated thread-safe scheduling helper for that case. ### What a Task adds A Task is constructed around a coroutine object. On creation it asks the loop to run its first step. Each step resumes the coroutine until it yields at an `await`; the Task then arranges to be woken when whatever it is waiting on completes, and schedules the next step. When the coroutine returns, the Task calls `set_result` **on itself**; when it raises, `set_exception` on itself. From the outside it looks exactly like a Future that fills itself in. That extra machinery gives Tasks members a bare Future does not have — most visibly `get_coro()` for the coroutine it is driving, plus name and stack introspection — and it changes what `cancel()` means. Cancelling a bare Future just marks the slot cancelled and wakes its waiters. Cancelling a Task requests that `CancelledError` be delivered *into* the running coroutine at its current suspension point, so the coroutine's `finally` blocks run. Same method name, meaningfully different act. ### Which one do you create? Almost always a Task, via `asyncio.create_task`. Reasons to make a bare Future are narrow but real: * Adapting a callback API (as above) or a completion notification from a transport. * Building a one-shot signal between coroutines where a full task would be overkill — although the synchronisation primitives usually express that better. * Writing a library that returns "something awaitable" whose value it will supply later. When you do make one, use the running loop's `create_future()` factory rather than constructing the class directly: a loop implementation may supply an optimised subclass. ### How the two meet at runtime The relationship is not just conceptual — it is the mechanism the loop actually uses. When a Task's coroutine awaits something that is not yet ready, what it ultimately awaits is a Future: a sleep registers a timer that will fill one, a socket read registers a reader callback that will fill one, a lock registers a waiter that will fill one. The Task attaches a done-callback to that Future which reschedules its own next step, then stops. So a Task is a small state machine parked on a Future, woken by that Future being completed, and completing a Future of its own at the end. Once you see that, `await` stops looking magical: every suspension in an asyncio program bottoms out in some Future that some callback will fill. This also explains a rule that otherwise looks arbitrary — why filling a Future from another thread is forbidden. The done-callbacks it fires are scheduled on one specific loop, and asyncio provides a separate thread-safe scheduling entry point precisely so cross-thread code has a legal way in. ### The name collision worth flagging `asyncio.Future` and `concurrent.futures.Future` are different classes with different assumptions. The executor one is thread-safe and has a blocking `result(timeout)`; the asyncio one is single-loop, non-blocking, and its `result()` never waits — it either gives you the outcome or raises `InvalidStateError`. Anything crossing between the two worlds needs an explicit adapter; that boundary is its own topic. ### How to say it in an interview "A Future is a result slot somebody else fills. A Task is a Future that fills itself by running a coroutine on the loop." Then add the two consequences that matter: awaiting either suspends you until it is done, but only a Task has a body — so only a Task can be cancelled *into*, and only a Task makes progress on its own.