On Fri, May 23, 2014 at 10:37 AM, Guido van Rossum <[email protected]> wrote:
> I very much like the idea of having at least the Future class of either > framework be compatible with the event loop classes of the other. > It would also be nice if asyncio could accept tornado Futures as well (which do not implement __iter__ but otherwise have the same interface). (and maybe concurrent.futures.Future, which has the same interface but requires its add_done_callbacks to be thread-safe). More generally, asyncio could define a @functools.singledispatch function to convert arbitrary yielded objects into asyncio.Futures. This would let libraries plug in their own adapters and you could handle completely different interfaces like Twisted Deferreds as well. I'm probably going to do this for Tornado's coroutines. (more discussion from the Tornado side at https://github.com/tornadoweb/tornado/pull/1041) -Ben > > We may even be able to make both frameworks' Task and coroutine compatible > with each others' loop. > > If this requires some adjustments to asyncio, so be it. (There are > probably some isinstance() checks that get in the way, we should do > something different.) > > I'm not sure that Trollius should have to bend over backwards to use > asyncio's base classes if they are available. > > > On Fri, May 23, 2014 at 2:51 AM, Victor Stinner > <[email protected]>wrote: > >> 2014-05-23 8:54 GMT+02:00 Saúl Ibarra Corretgé <[email protected]>: >> > Let me try to explain again :-) Assume I have a FooApp thing that >> > works with both trollius and it's designed to be Python 2 and 3 >> > compatible. This application wants to use aiodns now. aiodns doesn't >> > have a dependency on Python 3 or asyncio because it returns Future >> > objects, so it doesn't matter if I import Future from asyncio or >> > trollius. It does matter to FooApp, however. >> > >> > If FooApp is running on Python 3.4, it will still use trollius, but >> > when importing aiodns, it will import asyncio in turn. Not necessarily >> > a bad thing, but the Future objects returned by aiodns are >> > asyncio.Future, and I don't think that will work when doing yield From >> > or run_until_complete in trollius, will it? >> >> Oh ok, it's more complex than what I understood :-) >> >> I see 4 cases: >> >> (a) Application written for asyncio (or Tulip): Python 3.3+ >> (b) Application written for Trollius: Python 2.6+ >> (c) Application able to use asyncio or Trollius, prefer asyncio: Python >> 2.6+ >> >> - python 2.6-3.2: use Trollius, or ImportError if Trollius is not >> installed >> - python 3.3: use Tulip, or Trollius, or ImportError if none is >> installed >> - python 3.4+: use asyncio of the stdlib >> >> (d) Application able to use asyncio or Trollius, prefer Trollius: Python >> 2.6+ >> >> - python 2.6-3.2: use Trollius, or ImportError if Trollius is not >> installed >> - python 3.3: use Trollius, or Tulip, or ImportError if none is >> installed >> - python 3.4+: use Trollius, or Tulip, or use asyncio of the stdlib >> >> Well, the problem is not really with a single application. The problem >> is when a module doesn't use the same async library that the >> application! >> >> >> Use cases: >> >> (1) Application and module uses asyncio (or Tulip) >> (2) Application and module uses Trollius >> (3) Application uses Trollius, module uses asyncio (or Tulip) >> (4) Application uses asyncio (or Tulip), module uses Trollius >> >> The cases (1) and (2) should work without any issue. The problem is >> really when application and modules use different async modules, cases >> (3) and (4). >> >> My short test (see attached saul.py script) shows me that asyncio and >> trollius don't understand them: >> >> - It's not possible to set set an asyncio event loop in Trollius, same >> error for the opposite. >> >> - In debug mode, asyncio.async(<a trollius coroutine object>) raises a >> TypeError because asyncio checks for asyncio.Future type, not >> trollius.Future >> >> - When using an asyncio event loop, Trollius coroutine complains that >> the Return object was used without raise. The Trollius event loop sets >> the raised attribute of Return, whereas the asyncio loop doesn't. >> >> - I didn't spend much time on my test, there are probably much more >> issues. >> >> >> Maybe Trollius should try to cooperate with asyncio when asyncio is >> available on the system? For example, inherit asyncio classes (but >> override methods) instead of using a new hierachy of classes? >> >> Victor >> > > > > -- > --Guido van Rossum (python.org/~guido) >
