Stefan Behnel added the comment: > I find it questionable to mix await and threads, as I have said several > times in the discussion about Nick Coghlan's proposal to introduce > helper functions with a similar function.
There are a couple of use cases in the context of asyncio, but definitely also a major one: blocking database drivers. Normally, applications keep a pool of connections open to a database and use a bounded size for it in order to limit the resource usage on server side. Starting a thread pool of the same size in the application provides a trivial way to make use of these connections concurrently and efficiently with a blocking database driver and/or ORM (e.g. SQLAlchemy). "concurrent.futures" makes this really easy. > The argument "but they're both Futures" seems pretty bogus to me. concurrent.futures.Future is not just any Future, it's the one that is in the standard library, i.e. pretty much the only one that every tool could agree on (whether or not it knows about or uses asyncio). The fact that it's thread-safe doesn't really matter to me. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24383> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com