2014/1/3 Guido van Rossum <[email protected]>: > However, I don't like the dependency either (hence the TODO comment > :-). When I introduced it I didn't realize there were platforms where > concurrent.futures can't be imported. > > I would be fine with conditionally importing concurrent.futures and > using the constants from it, and when it can't be imported, define the > constants and exception classes locally.
Yes, it's possible to do that. I implemented this in Trollius 0.1 to try to mimick Tulip as much as possible. > However, that still leaves the use of a thread pool in > run_in_executor() -- how else are you going to call getaddrinfo() in a > separate thread? (Did you solve this in Trollius yet?) I would be okay > with a private backport of a minimal executor for this purpose. If concurrent.futures is missing, it's maybe possible to write a synchronous fallback used as a fallback? It's maybe better than raising an ImportError. Or concurrent.futures dependency can be mandatory. > Finally, on the one platform where concurrent.futures can't be > imported, isn't it because it doesn't have threads? concurrent.futures cannot be loaded on old FreeBSD 6 setup because of a limit on POSIX semaphores, not because thread support is disabled. I didn't try asyncio on Python compiled with thread support disabled. > So even a private > thread pool wouldn't solve the problem on that platform (though you > could get a lot more tests to pass). I guess nothing would solve the > problem on that platform except just calling getaddrinfo() in-line -- > I suppose you could have a dummy thread pool that uses the > dummy_threading stdlib module to minimize the conditional stuff you > have to do in the Tulip code. I'm not sure that it's worth to reimplement a pseudo concurrent.futures with something more complex than a synchronous executor. concurrent.futures is always present in Python 3.2+ and a backport is available for older Python versions. Victor
