+1000<br><br>Can we dream with gevent integrated to standard cpython ? This would be a fantastic path for 3.4 :)<br><br>And I definitely should move to 3.x. <br><br>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...<br><br> 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.<br><br>-- <br><span style="border-collapse:collapse;color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px">  Carlo Pires<br></span><br><br><div class="gmail_quote">2012/10/6 Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is an incredibly important discussion.<br>
<br>
I would like to contribute despite my limited experience with the<br>
various popular options. My own async explorations are limited to the<br>
constraints of the App Engine runtime environment, where a rather<br>
unique type of reactor is required. I am developing some ideas around<br>
separating reactors, futures, and yield-based coroutines, but they<br>
take more thinking and probably some experimental coding before I'm<br>
ready to write it up in any detail. For a hint on what I'm after, you<br>
might read up on monocle (<a href="https://github.com/saucelabs/monocle" target="_blank">https://github.com/saucelabs/monocle</a>) and my<br>
approach to building coroutines on top of Futures<br>
(<a href="http://code.google.com/p/appengine-ndb-experiment/source/browse/ndb/tasklets.py#349" target="_blank">http://code.google.com/p/appengine-ndb-experiment/source/browse/ndb/tasklets.py#349</a>).<br>
<br>
In the mean time I'd like to bring up a few higher-order issues:<br>
<br>
(1) How importance is it to offer a compatibility path for asyncore? I<br>
would have thought that offering an integration path forward for<br>
Twisted and Tornado would be more important.<br>
<br>
(2) We're at a fork in the road here. On the one hand, we could choose<br>
to deeply integrate greenlets/gevents into the standard library. (It's<br>
not monkey-patching if it's integrated, after all. :-) I'm not sure<br>
how this would work for other implementations than CPython, or even<br>
how to address CPython on non-x86 architectures. But users seem to<br>
like the programming model: write synchronous code, get async<br>
operation for free. It's easy to write protocol parsers that way. On<br>
the other hand, we could reject this approach: the integration would<br>
never be completely smooth, there's the issue of other implementations<br>
and architectures, it probably would never work smoothly even for<br>
CPython/x86 when 3rd party extension modules are involved.<br>
Callback-based APIs don't have these downsides, but they are harder to<br>
program; however we can make programming them easier by using<br>
yield-based coroutines. Even Twisted offers those (inline callbacks).<br>
<br>
Before I invest much more time in these ideas I'd like to at least<br>
have (2) sorted out.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
</div></div></blockquote></div><br><br>