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
