Can you provide something more concrete, like a design for an API? So far it seems you're just complaining. Nobody likes that.
On Sun, Oct 23, 2016 at 12:27 PM, Imran Geriskovan <[email protected]> wrote: >>> 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.. -- --Guido van Rossum (python.org/~guido)
