<br><br><div class="gmail_quote">On Sat, Oct 6, 2012 at 9:05 PM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Sat, Oct 6, 2012 at 7:22 PM, Josiah Carlson <<a href="mailto:josiah.carlson@gmail.com">josiah.carlson@gmail.com</a>> wrote:<br>
> On Sat, Oct 6, 2012 at 3:00 PM, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
>> 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>
> Yield-based coroutines like monocle are the simplest way to do<br>
> multi-paradigm in the same code. Whether you have a async-style<br>
> reactor, greenlet-style stack switching, cooperatively scheduled<br>
> generator trampolines, or just plain blocking threaded sockets; that<br>
> style works with all of them (the futures and wrapper around<br>
> everything just looks a little different).<br>
<br>
</div>Glad I'm not completely crazy here. :-)<br>
<div class="im"><br>
> That said, it forces everyone to drink the same coroutine-styled<br>
> kool-aid. That doesn't bother me. But I understand it, and have built<br>
> similar systems before. I don't have an intuition about whether 3rd<br>
> parties will like it or will migrate to it. Someone want to ping the<br>
> Twisted and Tornado folks about it?<br>
<br>
</div>They should be reading this. </blockquote><div><br>Yup, we are. I've pinged others in the Twisted cabal on this matter, so hopefully you'll be hearing from one or more of us soon...<br><br>d<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Or maybe we should bring it up on<br>
python-dev before too long.<br>
<div class="im"><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>
><br>
> Combining your responses to #1 and now this, are you proposing a path<br>
> forward for Twisted/Tornado to be greenlets? That's an interesting<br>
> approach to the problem, though I can see the draw. ;)<br>
<br>
</div>Can't tell whether you're serious, but that's not what I meant. Surely<br>
it will never fly for Twisted. Tornado apparently already works with<br>
greenlets (though maybe through a third party hack). But personally<br>
I'd be leaning towards rejecting greenlets, for the same reasons I've<br>
kept the doors tightly shut for Stackless -- I like it fine as a<br>
library, but not as a language feature, because I don't see how it can<br>
be supported on all platforms where Python must be supported.<br>
<br>
However I figured that if we define the interfaces well enough, it<br>
might be possible to use (a superficially modified version of)<br>
Twisted's reactors instead of the standard ones, and, orthogonally,<br>
Twisted's deferred's could be wrapped in the standard Futures (or the<br>
other way around?) when used with a non-Twisted reactor. Which would<br>
hopefully open the door for migrating some of their more useful<br>
protocol parsers into the stdlib.<br>
<div class="im"><br>
> I have been hesitant on the Twisted side of things for an arbitrarily<br>
> selfish reason. After 2-3 hours of reading over a codebase (which I've<br>
> done 5 or 6 times in the last 8 years), I ask myself whether I believe<br>
> I understand 80+% of how things work; how data flows, how<br>
> callbacks/layers are invoked, and whether I could add a piece of<br>
> arbitrary functionality to one layer or another (or to determine the<br>
> proper layer in which to add the functionality). If my answer is "no",<br>
> then my gut says "this is probably a bad idea". But if I start<br>
> figuring out the layers before I've finished my 2-3 hours, and I start<br>
> finding bugs? Well, then I think it's a much better idea, even if the<br>
> implementation is buggy.<br>
<br>
</div>Can't figure what you're implying here. On which side does Twisted fall for you?<br>
<div class="im"><br>
> Maybe something like Monocle would be better (considering your favor<br>
> for that style, it obviously has a leg-up on the competition). I don't<br>
> know. But if something like Monocle can merge it all together, then<br>
> maybe I'd be happy.<br>
<br>
</div>My worry is that monocle is too simple and does not cater for advanced<br>
needs. It doesn't seem to have caught on much outside the company<br>
where it originated.<br>
<div class="im"><br>
> Incidentally, I can think of a few different<br>
> styles of wrappers that would actually let people using<br>
> asyncore-derived stuff use something like Monocle. So maybe that's<br>
> really the right answer?<br>
<br>
</div>I still don't really think asyncore is going to be a problem. It can<br>
easily be separated into a reactor and callbacks.<br>
<div class="im"><br>
> Regards,<br>
>  - Josiah<br>
><br>
> P.S. Thank you for weighing in on this Guido. Even if it doesn't end<br>
> up the way I had originally hoped, at least now there's discussion.<br>
<br>
</div>Hm, there seemed to be plenty of discussion before...<br>
<div class="im HOEnZb"><br>
--<br>
--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)<br>
</div><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>