Using `concurrent.futures.Future` as promise

Question

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

Answer 1

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.