[Async-sig] A possible tiny step towards event loop interoperability

[Yury Selivanov]

> On Jun 3, 2016, at 10:53 PM, Glyph <glyph at twistedmatrix.com> wrote:
> 
> 
>> On Jun 3, 2016, at 17:07, Guido van Rossum <guido at python.org> wrote:
>> 
>> On Fri, Jun 3, 2016 at 3:26 PM, Nathaniel Smith <njs at pobox.com> wrote:
>>> Convincing everyone to agree on a single event loop API sounds hard.
>> 
>> Really? That was exactly the purpose of asyncio and PEP 484 (and Glyph
>> helped a lot, so I kind of feel he has to some extent endorsed that
>> design).
> 
> To echo that, the asyncio loop is a pretty solid basis for cross-framework compatibility.  It hasn't been completely zero-friction for Twisted to adopt it, but work is ongoing there and I don't think there are any blockers, aside from "time to make it happen".  But as has already come up on this thread, we're really talking about the coroutine scheduler.
> 
> Specifically where this came up in the openspace was in the ability to await a Deferred.  And "what event loop is this" is not entirely what we want to await, it is "give me the event loop".
> 
> Here's the problem: if an asyncio coroutine wants to await upon a Deferred, the Deferred does not know about the event loop.  But when a Deferred is awaited, it must answer two questions: (A), does it need to convert itself into a Future, or is the caller natively expecting a Deferred, and (B) if it needs to create a Future, what 'loop' should it be passing to said Future?


If we:

1. agree that asyncio.Future will continue to use call_soon for callbacks, and Deferreds will continue to just call them;

2. we replace isinstance(Future) checks with __isfuture__ attribute; 

3. Deferred adds __isfuture__, implements __await__(), add_done_callback() and cancel() methods;

then:

- Coroutines run with asyncio.Task will be able to await on Deferreds (created by Twisted code);

- Coroutines run with Twisted’s coroutine runner will be able to await on Futures (created by asyncio code).

Is that correct?  Or we need something else?

Thanks,
Yury