On Jun 3, 2016, at 10:53 PM, Glyph <glyph@twistedmatrix.com> wrote:
On Jun 3, 2016, at 17:07, Guido van Rossum <guido@python.org> wrote:
On Fri, Jun 3, 2016 at 3:26 PM, Nathaniel Smith <njs@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