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

Groups > comp.lang.python > #68233 > 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 17:44 +0000
    Re: which async framework? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-12 10:56 +1300
      Re: which async framework? Marko Rauhamaa <marko@pacujo.net> - 2014-03-12 00:18 +0200

#68233 — Re: which async framework?

Antoine Pitrou <solipsis@pitrou.net> wrote:

> Yes, why use a library when you can rewrite it all yourself?

This assumes something equivalent to the library will have to be written.
But if it can be replaced with something very minimalistic it is just
bloat. I would also like to respond that the select module and pywin32 are
libraries. So what we are talking about here is not using a library versus
issuing low-level system calls, but using a cross-platform library instead
of having separate modules with system calls for Linux, *BSD/Apple and
Windows.

Another thing is that co-routines and "yield from" statements just makes it
hard to follow the logic of the program. I still have to convince myself
that a library for transforming epoll function calls into co-routines is
actually useful. If it just turns otherwise readable code into something
most Python programmers cannot read it is better left out of the project.

Sturla

[toc] | [next] | [standalone]

#68241

Sturla Molden wrote:
> Another thing is that co-routines and "yield from" statements just makes it
> hard to follow the logic of the program. I still have to convince myself
> that a library for transforming epoll function calls into co-routines is
> actually useful.

It's not "epoll function calls" that the coroutine style is
intended to replace, it's complex systems of chained callbacks.
They're supposed to make that kind of logic *easier* to follow.
If you haven't had that experience, it may be because you've
only dealt with simple cases.

-- 
Greg

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

#68243

Gregory Ewing <greg.ewing@canterbury.ac.nz>:

> It's not "epoll function calls" that the coroutine style is intended
> to replace, it's complex systems of chained callbacks. They're
> supposed to make that kind of logic *easier* to follow. If you haven't
> had that experience, it may be because you've only dealt with simple
> cases.

The coroutines are definitely something to get into, although I'm
skeptical as well. Epoll and the associated idioms have been with us for
a long time and are well understood.

As for "easy to follow," unfortunately the complexities of network state
machines cannot be abstracted out, and the result is never exactly easy
to the eye.


Marko

[toc] | [prev] | [standalone]

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

csiph-web