Использование `concurrent.futures.Future` в качестве обещания
В Python docs Я вижу:
concurrent.futures.Future...... не следует создавать напрямую за исключением тестирования.
И я хочу использовать его в качестве обещания в своем коде, и я очень удивлен, что его не рекомендуется использовать так.
Мой прецедент:
У меня есть один поток, который считывает пакеты данных, поступающие из сокета, и у меня много обратных вызовов, вызываемых в зависимости от некоторой информации, содержащейся в пакетах. Пакеты - это ответы на запросы потребителей, и все потребители используют одно соединение. Каждый потребитель получает обещание и добавляет к нему некоторые обработчики, которые вызываются при получении ответа.
Поэтому я не могу использовать подкласс Executor здесь, потому что у меня есть только один поток, но мне нужно создать много фьючерсов (promises).
Promise - довольно распространенный метод программирования, и я думал, что Future - это реализация обещаний Python. Но если не рекомендуется использовать его как обещание, какие питонисты обычно используют для этой цели?
Примечание
Я использую Python 2.7 backport от concurrent.futures до 2.7
Ответы
Ответ 1
Совершенно нормально использовать Future, чтобы обернуть API-интерфейсы без обещаний в promises.
Причина, по которой он вообще не должен быть создан, заключается в том, что большинство людей создают фьючерсы напрямую, потому что они делают отложенный анти-шаблон и обертывают созданного будущего исполнителя другое будущее.
Стоит отметить, что эта будущая реализация очень слабая, она похожа на старые Java-фьючерсы, классный материал promises дает вам, как цепочка просто отсутствует. Стоит отметить, что такие языки, как JavaScript получили promises от Python Twisted, который имеет лучшую реализацию, даже если он переплетается с другими вещами.
