Futures and promises

A caller can receive an object representing an unfinished result and associate subsequent work with it. Consumers later obtain a value or failure without requiring the initiating call stack to block synchronously throughout the operation.

Python asyncio.Future lets coroutines await a result, exception, or cancellation, and allows repeated awaits of the same completed value. It also connects callbacks to async/await. The division of roles named Future and Promise varies across systems and should not be inferred from names alone.

References: [1] [2]

ECMAScript promises have mutually exclusive pending, fulfilled, and rejected states; the latter two are settled. Resolved is not synonymous with fulfilled: a promise can already be locked into following another promise while still awaiting its completion.

Python Futures have their own state rules: result on an unfinished object raises InvalidStateError, and attempting to set another result after completion is invalid. Following the interface’s state transitions avoids confusing submitted work with an available outcome.

References: [2] [1]

An eventual-result object does not itself prescribe a new thread. Asyncio Futures belong to an event-loop system, while concurrent.futures Futures accompany executors; their waiting, result, and callback interfaces also differ.

Cancellation likewise does not universally mean stopping all underlying work. Asyncio Task cancellation requests action from a coroutine, whereas Future cancellation has a different state contract. Users need to identify what advances the operation, who completes the result, and what can actually stop ongoing work.

References: [1] [3] [4]