[issue24383] consider implementing __await__ on concurrent.futures.Future

Stefan Behnel report at bugs.python.org
Sun Aug 2 21:38:59 CEST 2015


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 <report at bugs.python.org>
<http://bugs.python.org/issue24383>
_______________________________________


More information about the Python-bugs-list mailing list