On Sun, Oct 23, 2016 at 5:28 AM, Imran Geriskovan <[email protected]> wrote: > As I noted in my previous posts in this group, > I mostly try keeping async code with parity of > blocking code. (Reasons: Ease of streams based > development, Easy migration to compiled langs, > threads, etc, etc..) > > For couple of months I've been playing with > Curio, to which now I'm a total convert. > > For an async code based on Curio, you can almost > drop all "await/async" keywords with some > minor manupulations; and bang: You get working > blocking version. Or you can go from blocking > version to async. > > Even better, you can mix async and blocking code > in hybrid combinations to get best of both worlds. > (Ex: when using blocking libraries, performance > critical routines, etc..) > > With enough effort these can also be done with > asyncio. However, with Curio, this approach > is directly supported out of the box. And it's > a compact one without any bells and whistles. > It has nothing more than necessary to get > the job done. > > Performance of pure async code is about 2x with > respect to asyncio. And your millage may be > extended with hybrid blocking combinations. > > I'd be happy to see Curio in std library..
Dave has repeatedly stated that he's not interested in maintaining Curio long term or keeping the API stable. That means it's not going to happen. It might make more sense to propose carefully designed additions to asyncio that aim to fill in the gaps you've found by using curio. This should focus on API functionality; the performance is being worked on separately, and there's also uvloop. -- --Guido van Rossum (python.org/~guido)
