Re: [python-tulip] Curio

[Yury Selivanov]

> On Oct 24, 2016, at 12:38 PM, Xavier Combelle  
> wrote:
> 
> 
>> Yes, this is something that has to be fixed in asyncio docs.  
>> Protocols/transports are advanced low level concepts, you don’t need to even 
>> know about them to use asyncio programs.  I’ll try to find some time to work 
>> on the docs before 3.6 is released...
>> 
>> Yury
>> 
> 
> If I don't mistake, that is the high level api 
> https://docs.python.org/3.6/library/asyncio-stream.html#tcp-echo-client-using-streams
> looks like the api is different than sync ones (with notably one reader and 
> one writer) and that the loop is needed everywhere

Right, passing the “loop” explicitly is another point to fix in the docs.  
Short answer - don’t do that in your programs.  You might want to pass the loop 
explicitly when you’re working on a reusable library like aiohttp, but that’s 
about it.

We also can have a third-party package that would implement curio-like stream 
object and socket object if a lot of people think it’s easier to work with.  
This is something that can be easily addressed even with the current asyncio.

Yury

Re: [python-tulip] Curio

[Xavier Combelle]

> Yes, this is something that has to be fixed in asyncio docs.  
> Protocols/transports are advanced low level concepts, you don’t need to even 
> know about them to use asyncio programs.  I’ll try to find some time to work 
> on the docs before 3.6 is released...
>
> Yury

If I don't mistake, that is the high level
apihttps://docs.python.org/3.6/library/asyncio-stream.html#tcp-echo-client-using-streams
looks like the api is different than sync ones (with notably one reader
and one writer) and that the loop is needed everywhere

Re: [python-tulip] Curio

[Yury Selivanov]

> On Oct 24, 2016, at 12:24 PM, Xavier Combelle  
> wrote:
> 
> - the run function
> - the await, async keyword
> The other api are copy paste to the synchrone ones

Yes, this is something that has to be fixed in asyncio docs.  
Protocols/transports are advanced low level concepts, you don’t need to even 
know about them to use asyncio programs.  I’ll try to find some time to work on 
the docs before 3.6 is released...

Yury

Re: [python-tulip] Curio

[Xavier Combelle]

I might be wrong, but from my point of view it is about the API proposed.

The asyncio API is far more rich of new concept than curio one
there are at least protocols, ioloop
and to my knowledge you can't do write similar code of the tutorial
without using protocol and ioloop
at the opposite, the only new concept bring by the main of curio
tutorial are
- the run function
- the await, async keyword
The other api are copy paste to the synchrone ones

Le 24/10/2016 à 17:40, Andrew Svetlov a écrit :
> I believe it is documentation issue, not internal implementation problem.
>
> On Mon, Oct 24, 2016 at 6:31 PM Xavier Combelle
> > wrote:
>
>
> > 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.
> >
> I did not did really experienced asyncio by finding it too much
> complicated
> (and that I did not had real use case).
> But when I read curio documentation I found it wonderful to the point
> I want to experiment with it
> I would love to see something similar in python standard library as
> (from my point of view)
> it looks like more understandable than current asyncio.
>
> -- 
> Thanks,
> Andrew Svetlov

Re: [python-tulip] Curio

[Andrew Svetlov]

I believe it is documentation issue, not internal implementation problem.

On Mon, Oct 24, 2016 at 6:31 PM Xavier Combelle 
wrote:

>
> > 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.
> >
> I did not did really experienced asyncio by finding it too much complicated
> (and that I did not had real use case).
> But when I read curio documentation I found it wonderful to the point
> I want to experiment with it
> I would love to see something similar in python standard library as
> (from my point of view)
> it looks like more understandable than current asyncio.
>
> --
Thanks,
Andrew Svetlov

Re: [python-tulip] Curio

[Xavier Combelle]

> 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.
>
I did not did really experienced asyncio by finding it too much complicated
(and that I did not had real use case).
But when I read curio documentation I found it wonderful to the point
I want to experiment with it
I would love to see something similar in python standard library as
(from my point of view)
it looks like more understandable than current asyncio.

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