Well, as far as I can tell, futures
isn't documented to work on top of threading.Condition
, and gevent
isn't documented to be able to patch futures
safely. So, in theory, someone could write a Python implementation that would break gevent
.
But in practice? It's hard to imagine what such an implementation would look like. You obviously need some kind of sync objects to make a Future
work. Sure, you could use an Event
, Lock
, and Rlock
instead of a Condition
, but that won't cause a problem for gevent
. The only way an implementation could plausibly break things would be to go directly to the pthreads/Win32/Java/.NET/whatever sync objects instead of using the wrappers in threading
.
How would you deal with that if it happened? Well, futures
is implemented in pure Python, and it's pretty simple Python, and there's a fully functional backport that works with 2.5+/3.2+. So, you'd just have to grab that backport and swap out concurrent.futures
for futures
.
So, if you're doing something wacky like deploying a server that's going to run for 5 years unattended and may have its Python repeatedly upgraded underneath it, maybe I'd install the backport now and use that instead.
Otherwise, I'd just document the assumption (and the workaround in case it's ever broken) in the appropriate place, and then just use the stdlib module.