1

From the asyncio documentation it states that asyncio has:

"a Future class that mimics the one in the concurrent.futures module, but adapted for use with the event loop;"

Why is there a need to have two different Future classes in the standard library (in asyncio and in concurrent)? And why is there the necessity to adapt it for the event loop? What am I missing here, or what made them decide it that way?

Marcelo Duarte Fernandes
  • 64
  • 4

1 Answers1

3

Why is there a need to have two different Future classes in the standard library (in asyncio and in concurrent)?

While these classes looks similar, they are using for two different paradigms of concurrent programming and have different implementations and interfaces. For example,

concurrent.futures.Future used for thread/process based concurrent programming and shouldn't know nothing about event loop because there isn't one in this case. It's result method just blocks thread's/process's execution flow till timeout or future is done.

asyncio.Future used for coroutines based concurrent programming and should know about event loop, coroutine-functions and other related stuff. It's result method wouldn't block execution flow since execution flow shouldn't be block at all in this case. Instead you should await future till it's done allowing execution flow to be returned and managed by event loop.

There are no benefits in mixing them, while splitting classes makes theirs implementations easier and interfaces clearer.

Mikhail Gerasimov
  • 27,590
  • 10
  • 86
  • 127
  • 1
    More info https://stackoverflow.com/questions/43882301/why-is-asyncio-future-incompatible-with-concurrent-futures-future and https://stackoverflow.com/questions/29902908/what-is-the-difference-between-concurrent-futures-and-asyncio-futures – kwarunek Sep 10 '17 at 18:25