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

[Glyph]

> 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?

The reason the distinction is important is that if the caller natively expects a Deferred, then the callback chain can be invoked synchronously, whereas if the caller expects a Future, the loop needs to be made available for call_soon.  And it is the loop into which said Future will eventually be awaited that determines which one should be passed in.

For what it's worth, if Future didn't depend on the loop at all, but received the loop as an argument somehow along the awaitability chain, this issue would disappear (at least for this specific case).

Is that explanation clear?

-glyph