Hi, 2013/12/19 Marc Schlaich <[email protected]>: > - Would you consider moving to GitHub to attract (more) contributors, > including myself?
asyncio on python.org and Tulop on code.google.com both use Mercurial. I don't want to use a different SCM for the backport. > - concurrent.futures is already backported: > https://pypi.python.org/pypi/futures. You should completely drop this and > make it an (optional?) dependency. Oh, I didn't know that, it will check if it's possible and useful to reuse it. > - I would directly wrap coroutines in tasks in the decorator, this should > simplify things. This would be a completly different behaviour than asyncio for Python 3. I don't want to diverge from asyncio/Tulip. The backport is supposed to be a temporary option for applications stuck at Python 2. The idea is to first replace the current asyncio framework (gevent, eventlet, Twisted, Tornado, whatever) with tulip_py2, and then port the application to Python 3. Or the port to Python 3 can be in parallel. > - Using yield instead of yield from offers a nice syntax style to wait for > parallel execution of coroutines/tasks: > > twitter_data, fb_data = yield ( > async_http_request('http://twitter.com/...'), > async_http_request('http://facebook.com./...'), > ) > > This needs to be enabled in the scheduler. What do you think? Again, tulip_v2 should not diverge from Tulip/asyncio. asyncio.wait() should be used for this purpose. If you would like to have a different behaviour, you have to fork tulip_v2/Tulip and write your own library with a close but different API . Victor
