Question: what's the morale behind having a `asyncio.Future`?

[yangvz]

It seems that asyncio.Future is quite different from concurrent.futures.Future, for example, in terms of how cancellation works:

asyncio.Future.cancel() Cancel the future and schedule callbacks. If the future is already done or cancelled, return False. Otherwise, change the future’s state to cancelled, schedule the callbacks and return True.

concurrent.futures.Future.cancel() Attempt to cancel the call. If the call is currently being executed and cannot be cancelled then the method will return False, otherwise the call will be cancelled and the method will return True.

A concurrent future is "future" in the sense that it's return time is arbitrary, which is not the case for async tasks, whose return time is deterministic relative to the code with access to the task object.

[gvanrossum]

I presume you meant "rationale", not "morale". :-)

I'm not sure where you're going with this question -- are you asking why there are two Future types instead of one? Or are you wondering why they both have the same name? Or why they have different behavior?

I'm not sure how to answer any of those, because I don't know what context you already have about concurrent programming. But perhaps the Wikipedia article on Futures and promises is helpful?

[ldo]

Differences are listed here. It seems clear that asyncio.Future avoids any semantics that might implicitly block the caller; instead, such blocking must be explicit, through the await construct.