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.
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)
