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