Re: [python-tulip] Curio

Imran, I don’t think this is a productive discussion. FWIW it's possible to implement all of Curio’s APIs on top of current asyncio: there are no fundamental blockers to that. If you think that Curio is better in some regards, please feel free to post concrete proposals to

Re: [python-tulip] Curio

>> 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

Re: [python-tulip] Curio

On Sun, Oct 23, 2016 at 5:28 AM, Imran Geriskovan 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,

Re: [python-tulip] Curio

>> 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 an async code based on Curio, you can almost >> drop all

Re: [python-tulip] Curio

Hello, On Sun, 23 Oct 2016 15:28:20 +0300 Imran Geriskovan 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, >

[python-tulip] Curio

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.