58

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
  • 5,820
  • 7
  • 50
  • 69
  • For anyone needing to use `concurrent.futures Future` objects in code that uses `asyncio`, wrap the `Future` objects with [asyncio.wrap_future](https://docs.python.org/3/library/asyncio-future.html#asyncio.wrap_future), which makes them `awaitable`. – plafer Jul 23 '21 at 20:03

2 Answers2

31

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
  • 91,354
  • 19
  • 222
  • 219
  • 2
    So it isn't thread safe, unless you use `add_done_callback()`? – sargas Apr 27 '15 at 19:06
  • 7
    `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
  • 497,756
  • 71
  • 530
  • 681