Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #68207 > unrolled thread

Re: which async framework?

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: which async framework? Sturla Molden <sturla.molden@gmail.com> - 2014-03-11 10:17 +0000
    Re: which async framework? Marko Rauhamaa <marko@pacujo.net> - 2014-03-11 12:51 +0200
      Re: which async framework? Sturla Molden <sturla.molden@gmail.com> - 2014-03-11 11:18 +0000

#68207 — Re: which async framework?

Chris Withers <chris@simplistix.co.uk> wrote:
> Hi All,
> 
> I see python now has a plethora of async frameworks and I need to try 
> and pick one to use from:
> 
> - asyncio/tulip
> - tornado
> - twisted

Looking at Tornado's examples on the web I find this:

    tornado.ioloop.IOLoop.instance().start()

This single line of code says more than thousand words. But it boils down
to:

(1)  This was written by some Java guys.
(2)  Someone used Python to write Java.

And that's all I need to know about Tornado.


Sturla

[toc] | [next] | [standalone]

#68210

Sturla Molden <sturla.molden@gmail.com>:

> Looking at Tornado's examples on the web I find this:
>
> [...]
>
> (1)  This was written by some Java guys.

I have written several Python async "frameworks" starting from
select.epoll(). It's only a handful of lines of code (plus an AVL tree
implementation for timers). Then, I've had to implement the protocols
myself because the standard library implementations aren't amenable to
async processing.

Now, I've taken a brief look at the new asyncio and it looks as if it
has everything one would hope for (and then some). You'd still need to
supply the protocol implementations yourself.

Since the async framework is such a small piece of the puzzle and since
the edge-triggered mode of select.epoll() is a nicer programming model
than asyncio provides, I might stick with epoll. (Yes, it is specific to
linux.)


Marko

[toc] | [prev] | [next] | [standalone]

#68212

Marko Rauhamaa <marko@pacujo.net> wrote:

> Now, I've taken a brief look at the new asyncio and it looks as if it
> has everything one would hope for (and then some). You'd still need to
> supply the protocol implementations yourself.

Tulip (the new async module) is nice. But I am a bit confused as to how it
combines the IOCP model on Windows with the "readyness" signalling (epoll,
kqueue) on Linux, *BSD and Apple. Because these paradigms are so inherently
different, I don't see how both can be used effectively with the same
client code. But Guido/BDFL is a smart guy and probably knows this better
than me :)

Another thing is that there is no IOCP support on Solaris, AIX and z/OS
using Tulip, only Windows. But Windows is not the only OS with IOCP. I'd
prefer that over /dev/poll any day (does Tulip use /dev/poll by the way?) 

Sturla

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web