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

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

Send data to asyncio coroutine

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

Contents

  Send data to asyncio coroutine jcarmena@gmail.com - 2015-07-21 04:31 -0700
    Re: Send data to asyncio coroutine Ian Kelly <ian.g.kelly@gmail.com> - 2015-07-21 07:35 -0600
      Re: Send data to asyncio coroutine Javier <jcarmena@gmail.com> - 2015-07-28 14:17 -0700
        Re: Send data to asyncio coroutine Javier <jcarmena@gmail.com> - 2015-07-28 15:41 -0700
          Re: Send data to asyncio coroutine Ian Kelly <ian.g.kelly@gmail.com> - 2015-07-28 15:20 -0800
        Re: Send data to asyncio coroutine Ian Kelly <ian.g.kelly@gmail.com> - 2015-07-28 15:06 -0800
          Re: Send data to asyncio coroutine Rustom Mody <rustompmody@gmail.com> - 2015-07-28 19:52 -0700
          Re: Send data to asyncio coroutine Javier <jcarmena@gmail.com> - 2015-07-29 07:24 -0700
    Re: Send data to asyncio coroutine Javier <jcarmena@gmail.com> - 2015-08-01 09:07 -0700
      Re: Send data to asyncio coroutine Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-08-01 17:41 +0100
        Re: Send data to asyncio coroutine Javier <jcarmena@gmail.com> - 2015-08-01 11:22 -0700
          Re: Send data to asyncio coroutine Marko Rauhamaa <marko@pacujo.net> - 2015-08-01 21:38 +0300
            Re: Send data to asyncio coroutine Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-08-01 19:45 +0100
              Re: Send data to asyncio coroutine Javier <jcarmena@gmail.com> - 2015-08-01 12:07 -0700
                Re: Send data to asyncio coroutine Marko Rauhamaa <marko@pacujo.net> - 2015-08-01 22:14 +0300
                  Re: Send data to asyncio coroutine Javier <jcarmena@gmail.com> - 2015-08-01 17:50 -0700
                Re: Send data to asyncio coroutine Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-08-01 20:33 +0100
                Re: Send data to asyncio coroutine Chris Angelico <rosuav@gmail.com> - 2015-08-02 09:28 +1000
              Re: Send data to asyncio coroutine Marko Rauhamaa <marko@pacujo.net> - 2015-08-01 22:09 +0300
                Re: Send data to asyncio coroutine Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-08-01 20:29 +0100
      Re: Send data to asyncio coroutine Marko Rauhamaa <marko@pacujo.net> - 2015-08-01 20:18 +0300
        Re: Send data to asyncio coroutine Javier <jcarmena@gmail.com> - 2015-08-01 10:50 -0700
          Re: Send data to asyncio coroutine Marko Rauhamaa <marko@pacujo.net> - 2015-08-01 21:33 +0300

Page 2 of 2 — ← Prev page 1 [2]

#94846

Javier <jcarmena@gmail.com>:

> Asyncio is a crazy headache! I realized that I can't use asyncio tcp
> servers with pickle! Asyncio is good as a concept but bad in real
> life.
>
> I think python's non blocking I/O is far from being something useful
> for developers till non-async code can invoke async code
> transparently. Duplicating all code/libs when you realize that
> something not fits asyncio is not a solution and even less a pythonic
> solution.

After all these decades, we are still struggling to find the naturally
flowing paradigm for asynchronous programming. Different
approaches/libraries/frameworks don't usually mix well or at all.

First, I believe it has been a grave mistake to write a ton of utility
libraries that block. They make it easy to put together a prototype, but
before long you realize the mess they have led you to and the only way
out is a complete rewrite or a number of complicated adapters that drain
performance, hurt quality and don't really add true value.

Could asyncio be the basis of a de-facto Python way of doing
asynchronous programming? Maybe. GvR definitely has that intention.
However, I'm afraid the paradigm is quite unnatural. Essentially, it is
thread programming where blocking calls are replaced with funny syntax.
Most developers are familiar with multithreading, but they often are not
actively aware what functions are blocking. Reading from a socket is
blocking. Writing to a socket is blocking as well. Is file I/O blocking?
Is database access blocking? Is socket.getaddrinfo() blocking?

A function may be nonblocking in one release of a package but might then
become blocking in the next release.

I'm an advocate of the "callback hell" together with clearly expressed
finite state machines. They are super easy to understand. They lead to
very complicated code but the complications can be analyzed and debugged
based on the elementary knowledge. Also, you don't need a complicated
framework for it. The only thing missing from select.epoll() is timers,
but timers are not all that hard to implement (especially if you had an
a balanced tree implementation at your disposal).

Still, even the select.epoll() method requires callback implementations
of the different protocols and databases.


Marko

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

#94847

El sábado, 1 de agosto de 2015, 19:19:00 (UTC+2), Marko Rauhamaa  escribió:
> Javier <jcarmena@gmail.com>:
> 
> > Asyncio is a crazy headache! I realized that I can't use asyncio tcp
> > servers with pickle! Asyncio is good as a concept but bad in real
> > life.
> >
> > I think python's non blocking I/O is far from being something useful
> > for developers till non-async code can invoke async code
> > transparently. Duplicating all code/libs when you realize that
> > something not fits asyncio is not a solution and even less a pythonic
> > solution.
> 
> After all these decades, we are still struggling to find the naturally
> flowing paradigm for asynchronous programming. Different
> approaches/libraries/frameworks don't usually mix well or at all.
> 
> First, I believe it has been a grave mistake to write a ton of utility
> libraries that block. They make it easy to put together a prototype, but
> before long you realize the mess they have led you to and the only way
> out is a complete rewrite or a number of complicated adapters that drain
> performance, hurt quality and don't really add true value.
> 
> Could asyncio be the basis of a de-facto Python way of doing
> asynchronous programming? Maybe. GvR definitely has that intention.
> However, I'm afraid the paradigm is quite unnatural. Essentially, it is
> thread programming where blocking calls are replaced with funny syntax.
> Most developers are familiar with multithreading, but they often are not
> actively aware what functions are blocking. Reading from a socket is
> blocking. Writing to a socket is blocking as well. Is file I/O blocking?
> Is database access blocking? Is socket.getaddrinfo() blocking?
> 
> A function may be nonblocking in one release of a package but might then
> become blocking in the next release.
> 
> I'm an advocate of the "callback hell" together with clearly expressed
> finite state machines. They are super easy to understand. They lead to
> very complicated code but the complications can be analyzed and debugged
> based on the elementary knowledge. Also, you don't need a complicated
> framework for it. The only thing missing from select.epoll() is timers,
> but timers are not all that hard to implement (especially if you had an
> a balanced tree implementation at your disposal).
> 
> Still, even the select.epoll() method requires callback implementations
> of the different protocols and databases.
> 
> 
> Marko

I agree with you, Marko, I came from callbacks too. So, if GvR wants the yield from become de-facto, does it mean that all python libraries will evolve to become asyncio friendly libs? or that I have to write my own library so I can use existing libraries like pickle? I think "callback hell" is "peccata minuta" compared with "yield from hell".

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

#94849

Javier <jcarmena@gmail.com>:

> I agree with you, Marko, I came from callbacks too. So, if GvR wants
> the yield from become de-facto, does it mean that all python libraries
> will evolve to become asyncio friendly libs? or that I have to write
> my own library so I can use existing libraries like pickle? I think
> "callback hell" is "peccata minuta" compared with "yield from hell".

I guess GvR expects Twisted, Tornado et al jump on the asyncio
bandwagon.

Myself, I would like the lowest-level I/O transactions to be broken into
their atomic, nonblocking primitives:

    request       optional: update(s), cancellation
    response      optional: preliminary response(s)

Those primitives can be then used to put together asyncio coroutines or
blocking functions for multithreading. Or they can be used as-is in
classical callback programming.


Marko

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web