44

To clarify the reason for this question:

  1. It is confusing to use two modules with the same name. What do they represent that makes them distinct?

  2. What task(s) can one solve that the other can't and vice-versa?

sargas
  • 4,422
  • 5
  • 43
  • 62

2 Answers2

21

The asyncio documentation covers the differences:

class asyncio.Future(*, loop=None)

This class is almost compatible with concurrent.futures.Future.

Differences:

  • result() and exception() do not take a timeout argument and raise an exception when the future isn’t done yet.
  • Callbacks registered with add_done_callback() are always called via the event loop’s call_soon_threadsafe().
  • This class is not compatible with the wait() and as_completed() functions in the concurrent.futures package.

This class is not thread safe.

Basically, if you're using ThreadPoolExecutor or ProcessPoolExecutor, or want to use a Future directly for thread-based or process-based concurrency, use concurrent.futures.Future. If you're using asyncio, use asyncio.Future.

dano
  • 78,755
  • 12
  • 192
  • 204
  • 2
    So it isn't thread safe, unless you use `add_done_callback()`? – sargas Apr 27 '15 at 19:06
  • 4
    `asyncio.Future` isn't thread-safe at all - it's only designed to be used in a single-threaded, `asyncio`-based application. If you want to call a method on `asyncio.Future` from a thread outside of the event loop thread, you'd need to use `loop.call_soon_threadsafe`. – dano Apr 27 '15 at 20:10
4

From the docs:

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

chepner
  • 389,128
  • 51
  • 403
  • 529