I personally don't have strong motivation for supporting both asyncio and trollius in aiohttp. My company uses Python 3.4 for asyncio-based projects. Getting rid of `yield from` and using Future objects everywhere in the project makes code much more complicated and increases maintenance cost. Sure, Nikolay Kim shares my opinion. Moreover, we are doing some refactoring now (replacing email.Message with MultiDict for HTTP header processing). Also we want to make highlevel server API (current one is too complex to use by average developer). Thus at least for now (at least for next couple months) better to keep aiohttp code small and simple. If some volunteer will invest own time in trollius support after stabilization of aiohttp API -- welcome!
On Tue, Jun 3, 2014 at 6:15 AM, Guido van Rossum <[email protected]> wrote: > I expect most apps to just fix either trollius or asyncio, but I encourage > libraries like aiohttp to support both. > > I will also consider changes to asyncio to improve interop -- I looked into > allowing set_event_loop() with a Trollius event loop, but I am too busy to > complete the project for now. > > --Guido > > > On Mon, Jun 2, 2014 at 1:34 AM, Victor Stinner <[email protected]> > wrote: >> >> 2014-06-01 14:51 GMT+02:00 Tobias Oberstein <[email protected]>: >> > Hi, >> > >> > I missed that discussion. >> > >> > IMHO, the renaming further complicates matters, since now selecting >> > networking library must be done consistently in both library and app >> > code. >> >> Please re-read this thread: it was discussed to make Trollius and >> asyncio compatible. I don't think that an asyncio event loop should >> support Trollius coroutines (there is an explicit test to reject >> coroutines using "yield", only "yield from" is allowed), but a >> Trollius event loop should support asyncio coroutines and asyncio >> futures (Future and Taks objects) as well. >> >> Trollius project cannot be popular (widely used) if popular asyncio >> modules like aiohttp don't work on it. I agree that I broke something >> in Trollius 0.3, but I plan to fix it in Trollius 0.4 and in asyncio. >> And I need your help to fix it ;-) >> >> Remember that asyncio is supposed to be interoperable with other async >> libraries, so it would be a shame that asyncio is not compatible with >> "itself" (with Trollius) ;-) >> >> >> By the way, if all applications and modules use the following >> "try/except ImportError" code, there is no need to worry. Right? >> >> --- >> try: >> # Use builtin asyncio on Python 3.4+, or Tulip on Python 3.3 >> import asyncio >> except ImportError: >> # Use Trollius on Python <= 3.2 >> import trollius as asyncio >> --- >> >> Using such code, your application can also use modules supporting only >> asyncio like aiohttp when running on Python 3.3+. (I'm not sure that >> it's very useful since you need to have a "fallback" on Python 2.) >> >> Victor > > > > > -- > --Guido van Rossum (python.org/~guido) -- Thanks, Andrew Svetlov
