Re: [python-tulip] Curio

[Yury Selivanov]

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 github.com/python/asyncio, let’s 
discuss.  We’ve implemented 10s of proposals that added new APIs in the past 
few years.

Yury

> On Oct 23, 2016, at 5:17 PM, Imran Geriskovan  
> wrote:
> 
> On 10/23/16, Guido van Rossum  wrote:
>> Can you provide something more concrete, like a design for an API?
> 
> I wont. But there is already a very good example.
> 
>> So far it seems you're just complaining. Nobody likes that.
> 
> There is no complaining.  I'm already on my way.
> Here, I'll respectfully aggree with anyone objecting any discussion
> about any python async engine other than asyncio. That's
> understandable.
> 
>>> Providing direct async versions of blocking operations is the
>>> key. That's it.

Re: [python-tulip] Curio

[Imran Geriskovan]

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

Re: [python-tulip] Curio

[Guido van Rossum]

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

Re: [python-tulip] Curio

[Imran Geriskovan]

>> 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 "await/async" keywords with some
>> minor manupulations; and bang: You get working
>> blocking version. Or you can go from blocking
>> version to async.

> Thanks for sharing your experiences.

You're welcome.

> So, it's the same motivation as for MicroPython's uasyncio which was
> presented on this list previously.

I think, it is good to see such a class of async implementations.
I can even release my own version of hacks for running asyncio
in the same spirit. However, I found Curio much more elegant,
so dumped most of it.

After some settlement about the direction, with such async
engines around, I'd expect Python standard library
to support a similar approach.

It is much more than async/sync write().

Regards,
Imran

Re: [python-tulip] Curio

[Paul Sokolovsky]

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

Thanks for sharing your experiences.

Quoiting from Curio's README:

"Existing I/O libraries are mainly built on event-loops, callback
functions, futures, and various abstractions that predate Python's
proper support for coroutines. As a result, they are either overly
complicated or dependent on esoteric magic involving C extensions,
monkeypatching, or reimplementing half of the TCP flow-control
protocol."

So, it's the same motivation as for MicroPython's uasyncio which was
presented on this list previously.

Looking at an example:

"""
await client.sendall(data)
"""

So, Curio consistently uses asynchronous reads and write for sockets,
unlike asyncio, which suddenly has synchronous write. And being asked
why, the author of the library says "but because reads and writes are
very different!" Well, now we have an alternative explanation - because
of "reimplementing half of the TCP flow-control protocol".



-- 
Best regards,
 Paul  mailto:pmis...@gmail.com

[python-tulip] Curio

[Imran Geriskovan]

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

Regards,
Imran