[Python-ideas] asyncore: included batteries don't fit

[Carlo Pires]

+1000

Can we dream with gevent integrated to standard cpython ? This would be a
fantastic path for 3.4 :)

And I definitely should move to 3.x.

Because for web programming, I just can't think another way to program
using python. I'm seeing some people going to other languages where async
is more easy like Go (some are trying Erlang). Async is a MUST HAVE for web
programming these days...

In my experience, I've found that "robustness of cooperative
multithreading" come at the price of a code difficult to maintain. And, in
single threading it never reach the SMP benefits with easy. Thats why
erlang shines... it abstracts the hard work of to maintain the switching
under control. Gevent walks the same line: makes the programmer life easier.

-- 
  Carlo Pires


2012/10/6 Guido van Rossum <guido at python.org>

> This is an incredibly important discussion.
>
> I would like to contribute despite my limited experience with the
> various popular options. My own async explorations are limited to the
> constraints of the App Engine runtime environment, where a rather
> unique type of reactor is required. I am developing some ideas around
> separating reactors, futures, and yield-based coroutines, but they
> take more thinking and probably some experimental coding before I'm
> ready to write it up in any detail. For a hint on what I'm after, you
> might read up on monocle (https://github.com/saucelabs/monocle) and my
> approach to building coroutines on top of Futures
> (
> http://code.google.com/p/appengine-ndb-experiment/source/browse/ndb/tasklets.py#349
> ).
>
> In the mean time I'd like to bring up a few higher-order issues:
>
> (1) How importance is it to offer a compatibility path for asyncore? I
> would have thought that offering an integration path forward for
> Twisted and Tornado would be more important.
>
> (2) We're at a fork in the road here. On the one hand, we could choose
> to deeply integrate greenlets/gevents into the standard library. (It's
> not monkey-patching if it's integrated, after all. :-) I'm not sure
> how this would work for other implementations than CPython, or even
> how to address CPython on non-x86 architectures. But users seem to
> like the programming model: write synchronous code, get async
> operation for free. It's easy to write protocol parsers that way. On
> the other hand, we could reject this approach: the integration would
> never be completely smooth, there's the issue of other implementations
> and architectures, it probably would never work smoothly even for
> CPython/x86 when 3rd party extension modules are involved.
> Callback-based APIs don't have these downsides, but they are harder to
> program; however we can make programming them easier by using
> yield-based coroutines. Even Twisted offers those (inline callbacks).
>
> Before I invest much more time in these ideas I'd like to at least
> have (2) sorted out.
>
> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20121006/3dd5c953/attachment.html>