>> 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.
Providing direct async versions of blocking operations is the key. That's it. Curio just does that. At the surface its that simple. Is providing this on asyncio possible? I've carried some hacks for asyncio streams. However covering async versions of all blocking use cases at some point required some kind of dirty hack involving going into async internals. Frankly I've given up. I dont think a carefully designed patch can solve it. I've ended up with this: Async programming is good, as long as it is the mirror image of blocking one. Inverting the control and then trying to get it back is not a good design. As I've tried it once..
