> > The strict API compatibility requirements of core Python stdlib, coupled > with the very long feature release life-cycles of Python, make me think > this sort of thing perhaps is better built in an utility library on top > of asyncio, rather than inside asyncio itself? 18 months is a long long > time to iterate on these features. I can't wait for Python 3.8... >
A lot of my late requests come from my attempt to group some of that in a lib: https://github.com/Tygs/ayo Most of it works, although I got read of context() recently, but the lazy task part really fails. Indeed, the API allows to do: async with ayo.scope() as run: task_list = run.all(foo(), foo(), foo()) run.asap(bar()) await task_list.gather() run.asap(baz()) scope() return a nursery like object, and this works perfectly, with the usual guaranty of Trio's nursery, but working in asyncio right now. However, I tried to add to the mix: async with ayo.scope(max_concurrency=2) as run: task_list = run.all(foo(), foo(), foo()) run.asap(bar()) await task_list.gather() run.asap(baz()) And I can get it to work. task_list will right now contains a list of tasks and None, because some tasks are not scheduled immediately. That's why I wanted lazytasks. I tried to create my own lazy tasks, but it never really worked. I'm going to try to go down the road of wrapping the unscheduled coro in a future-like object as suggested by Yuri. But having that built-in seems logical, elegant, and just good design in general: __init__ should not have side effects. _______________________________________________ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com