<br><br>On Saturday, October 6, 2012, Devin Jeanpierre  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Oct 7, 2012 at 12:05 AM, Guido van Rossum <<a>guido@python.org</a>> wrote:<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>
<br>
I thought futures were meant for thread and process pools? The<br>
blocking methods make them a bad fit for an asynchronous networking<br>
toolset.</blockquote><div><br></div><div>The specific Future implementation in the py3k stdlib uses threads and is indeed meant for thread and process pools.</div><div><br></div><div>But the *concept* of futures works fine in event-based systems, see the link I posted into the NDB sources. I'm not keen on cancellation and threadpools FWIW.<span></span><span></span></div>

<div> <br></div><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The Twisted folks have discussed integrating futures and Twisted (see<br>
also the reply, which has some corrections):<br>
<br>
<a href="http://twistedmatrix.com/pipermail/twisted-python/2011-January/023296.html" target="_blank">http://twistedmatrix.com/pipermail/twisted-python/2011-January/023296.html</a><br>
<br>
-- Devin<br>
</blockquote>
<br><br>-- <br>--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)<br>