concurrent futures, async futures and await

[Nagy László Zsolt]

>>
>> Simply because the concurrent future returned by executor.submit does
>> not implement __await__ and so it cannot be awaited for.
> I get that, but what happens if you try wrapping the executor.submit
> call with tornado.gen.convert_yielded as the tornado docs suggest and
> as I suggested above?
Thanks, it did the right thing. :-) (The tornado docs needs to be
updated where it talks about changing normal coroutines to native
coroutines.)

>> Of course, asyncio should not care if the executor is doing the task in
>> a different thread or a different process. All I'm saying is that
>> concurrent.futures.Future should implement the __await__ method, and
>> asyncio should be able to use it.
> I found this in the original PEP at
> http://legacy.python.org/dev/peps/pep-3156/#futures:
>
> """
> In the future (pun intended) we may unify asyncio.Future and
> concurrent.futures.Future, e.g. by adding an __iter__() method to the
> latter that works with yield from. To prevent accidentally blocking
> the event loop by calling e.g. result() on a Future that's not done
> yet, the blocking operation may detect that an event loop is active in
> the current thread and raise an exception instead. However the current
> PEP strives to have no dependencies beyond Python 3.3, so changes to
> concurrent.futures.Future are off the table for now.
> """
I was not aware of this. Thank you for pointing out.
>
> Maybe we're now far enough into the future that this could be
> reconsidered. In the meantime, the user does have other options:
>
> 1) For tornado, use tornado.gen.convert_yielded.
>
> 2) For asyncio, create an asyncio future and link them by setting a
> callback on the concurrent future that propagates the result (using
> call_soon_threadsafe since the callback may run in another thread).
>
> 3) Better, don't use concurrent.futures directly in the first place;
> instead use https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.AbstractEventLoop.run_in_executor
> which runs a function in an Executor and wraps it up via #2
> transparently.
That is the best. I have discovered another anomaly:

asyncio names this "run_in_executor" but tornado names it
"run_on_executor" (
http://www.tornadoweb.org/en/stable/concurrent.html#tornado.concurrent.run_on_executor
)

I hope eventually they will become fully compatible. :-)

Thanks for your help!

   Laszlo