<div dir="ltr"><br><div class="gmail_quote">On Thu, Aug 11, 2011 at 10:56 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Thu, Aug 11, <a href="tel:2011" value="+9722011">2011</a> at 5:07 PM, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
> Le Thu, 11 Aug <a href="tel:2011" value="+9722011">2011</a> 09:03:35 +1000,<br>
> Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> a écrit :<br>
>> On Thu, Aug 11, <a href="tel:2011" value="+9722011">2011</a> at 4:55 AM, Brian Curtin <<a href="mailto:brian.curtin@gmail.com">brian.curtin@gmail.com</a>><br>
>> wrote:<br>
>> > Now that we have concurrent.futures, is there any plan for<br>
>> > multiprocessing to follow suit? PEP <a href="tel:3148" value="+9723148">3148</a> mentions a hope to add or move<br>
>> > things in the future [0], which would be now.<br>
>><br>
>> As Jesse said, moving multiprocessing or threading wholesale was never<br>
>> part of the plan. The main motivator of that comment in PEP <a href="tel:3148" value="+9723148">3148</a> was<br>
>> the idea of creating 'concurrent.pool', which would provide a<br>
>> concurrent worker pool API modelled on multiprocessing.Pool that<br>
>> supported either threads or processes as the back end, just like the<br>
>> executor model in concurrent.futures.<br>
><br>
> Executors *are* pools, so I don't know what you're talking about.<br></blockquote><div><br></div><div>Also the Pool from multiprocessing "works" for threads and process:</div><div><br></div><div>from multiprocessing.pool import Pool as ProcessPool</div>
<div>from multiprocessing.dummy import Pool as ThreadPool </div></div></div>