ayo

_soon(self, *coros: typing.Coroutine): for coro in coros: self.tasks.add(asyncio.create_task(coro)) async def __aenter__(self): return self async def __aexit__(self, *args): try: while self.tasks: tasks = self.tasks self.tasks = set() done, pending = await asyncio.wait( tasks, return_when=asyncio.FIRST_COMPLETED ) try: for task in done: await task finally: self.tasks |= pending finally: for task in self.tasks: task.cancel() [1] https://stackoverflow.com/questions/60287285/starlette-async... [2] https://github.com/encode/starlette/issues/947

lly frees you of. Yuri is thinking about how to implement the trio solution (the infamous nursery) in uvloop, and if he does, we usually get the feature ported to the stdlib a year later. Meanwhile, I noted that a simple wrapper does meet the Pareto requirement: https://github.com/Tygs/ayo/ You can see it's not really hard to write your own version of it if you need to. It helped me a lot: the code is easier to reason about, and you remove a lot of edge cases. I'll have to test Janus, it seems super nice.

s a smaller API). But this ship has sailed. We have asyncio now. asyncio is pretty good honestly. But it needs some love. So, considering asyncio is what we have to work with, and by experience, it's quite great if you know what you are doing, I advice people to actually write a wrapper around it. If you don't feel like writing a wrapper, I'll plug in the one I'm working on in case people are curious: https://github.com/Tygs/ayo It: - is based on asyncio. Not a new framework. Integrated transparently with normal asyncio. - implement some lessons leaned from trio (e.g: nurseries, cancellation, etc) - expose a sweet API (running blocking code is run.aside(callback, args, *kwargs), and automate stuff it can (@ayo.run_as_main setup the event loop and run the function in one row) - make hard things decent: timeout and concurrency limit are just a param away I does need some serious doc, including a rich tutorial which features a pure asyncio part. Also it needs some mix between streams and protocols. I'm not going to skip that part, I think it's mandatory, but I'll need many months to make the whole thing. Now, I am not Nathaniel or Yury, so my work is not nearly as bullet proof as theirs. I would not advice to install ayo in prod now, but I think it's a great proof of concept of how good asyncio can be. And we most certainly can do even better.

ying to fix it. Nathaniel J. Smith is creating trio, a much simpler, saner alternative to asyncio: https://github.com/python-trio/trio Yury Selivanov is fixing the stdlib, and experiments with better concepts on uvloop first to integrated them later. E.G: Python 3.8 should have trio's nurseries integrated in stdlib. Personally, I don't want to wait for 3.8, and I certainly don't want the ecosystem to be fragmented between asyncio, trio or even curio. We already had the problem with twisted, tornado and gevent before. So I'm working on syntaxic sugar on top of asyncio: https://github.com/Tygs/ayo The goal is to make the API clean, easy to use, and that enforced the best practices, but stay 100% compatible with asyncio (it uses it everywhere) and it's ecosystem so that we don't get yet-another-island. It's very much a work in progress, but I think it demonstrate the main idea: asyncio is pretty good already, it just needs a little love.

, an event loop policy, awaitable, coroutines, coroutine functions, futures, tasks and task factories. But there is worse... You can setup any event loop any way and time you want, and because the api is public, another lib can come and swap it. No lib to my knowledge provide any form of locking. This leads to some weird situation where libs are considered so low level you end up writing wrappers on top of it (e.g: https://github.com/Tygs/ayo) just to be able to start using it sanely. Now compare with JS. I'm really not a fan of the language. However, even when you can't use async/await, using a promise is straightforward. You don't have to bother about creating the loop, starting it, stopping it, cleaning after it has stopped. You don't have to wonder if somebody is going to swap the loop. You don't have to get a reference to a loop to schedule anything. Actually you can mostly ignore the loop and just code the solution to your problem. Now this makes JS dependent on one loop implementation for each runtime. Also you can't code any new async feature in JS, only use the existing ones. It's probably not what you want for a language like rust. However, you should learn from the python ecosystem fragmentation and overly exposed low level API to avoid the same mistakes. Somebody that just wants to use async/await should not have to learn how the implementation works in details, nor take so much precaution to avoid implementation lock in or break somebody else work. And you really want a federated ecosystem. Having 7 incompatible websocket lib sucks.