2012/10/6 Guido van Rossum
<guido@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)