[Async-sig] asyncio <-> twisted interoperability

[Yury Selivanov]

[..]
> 1. Unlike Futures, Deferred objects know nothing about the event loop.  Deferred calls its callbacks directly, while Future uses ‘loop.call_soon’ to ensure fair scheduling.
> 
> asyncio Futures know about their event loop, but concurrent futures and Tornado futures do not. asyncio is the odd one out here, and I think it would be better to make asyncio futures call their callbacks directly than to introduce knowledge of the event loop to other deferred/future-like objects.

Please see my reply to Lukasz.  In short there are some problems with changing how asyncio currently works.

[..]
> Why make it asyncio specific? What you need is A) does it have an add_done_callback() method with the right interface, and B) are callbacks guaranteed to be run on the same thread (as with asyncio Futures) or is the thread unspecified (as in concurrent Futures). The latter isn't really a type-level check, so maybe Future instances should be associated with a thread (rather than an event loop). 

Yes, (A) and (B) are both important, and they define a minimal set of requirements.  I’d say the Future should also be an awaitable, and support ‘set_result’ and other methods.

Associating Futures with threads is a neat idea, but maybe, a special attribute like __isfuture__ is the simplest option?

Yury