12

In the Python docs I see:

concurrent.futures.Future... ...should not be created directly except for testing.

And I want to use it as a promise in my code and I'm very surprised that it is not recommended to use it like this.

My use case:
I have a single thread that reads data packets coming from socket, and I have many callbacks that are called depending on some information contained in packets. Packets are responses to consumers requests, and all consumers use single connection. Each consumer receives a promise and adds some handlers to it, that are invoked when response arrives.

So I cant use Executor subclass here, because I have only one thread, but I need to create many Futures (promises).

Promise is pretty widespread programming technique and, I thought that Future is Python's promise implementation. But if it is not recommended to use it like promise, what pythonistas are commonly use for this purpose?

Note

I use Python 2.7 backport of concurrent.futures to 2.7

Gill Bates
  • 14,330
  • 23
  • 70
  • 138
  • The Executor class does not even implement creating futures - subclasses do. I just used the Future class. There was no problem with this. Maybe the author knows why this is written there. – User Nov 10 '14 at 08:23
  • @User I meant subclass. I think I will just use them too. p.s. Cool nickname. – Gill Bates Nov 10 '14 at 08:46

1 Answers1

8

It's perfectly fine to use Future in order to wrap non-promise APIs into promises.

The reason it generally should not be created is because most times people create futures directly it's because they're doing the deferred anti pattern and wrapping an executor created future in another future.

It's worth mentioning that this future implementation is very weak, it's akin to Java's old futures, the cool stuff promises give you like chaining is simply missing. It's worth mentioning that languages like JavaScript got their promises from Python's Twisted, which has a better implementation, even if it's intertwined with other things.

Community
  • 1
  • 1
Benjamin Gruenbaum
  • 270,886
  • 87
  • 504
  • 504
  • What can you say about the docs? [_"should not be created directly except for testing"_](https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.Future) or [_"should only be used by Executor implementations and unit tests"](https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.Future.set_result) - these are very precise statements, they are explicitly say, where `Future` should created directly and prohibit everything else. – Gill Bates Nov 10 '14 at 09:28
  • Re: "cool stuff promises give you like chaining is simply missing" - that annoyed me greatly, so put together `concurrent.futures.Future` extended to support Promises/A+ `.then(success, error)` API (https://github.com/dvdotsenko/python-future-then) – ddotsenko Feb 08 '16 at 09:00
  • "Python's Twisted, which has a better implementation": you mean Twisted implementation is better compared to `concurrent.futures`, not compared to to JavaScript, right? I was under the impression that a Promises/A+ compliant implementation is superior to Twisted - and IIUC by now all popular JavaScript implementations include Promise/A+ compliance plus some helpful extras. – max May 17 '17 at 21:49
  • @max you understand correctly - although modern Python has better futures now anyway. – Benjamin Gruenbaum May 21 '17 at 07:42