RetroSearch Browse

Thu Aug 11 11:58:06 CEST 2011 · https://mail.python.org/pipermail/python-dev/2011-August/112798.html

On Thu, Aug 11, 2011 at 10:56 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Thu, Aug 11, 2011 at 5:07 PM, Antoine Pitrou <solipsis at pitrou.net>
> wrote:
> > Le Thu, 11 Aug 2011 09:03:35 +1000,
> > Nick Coghlan <ncoghlan at gmail.com> a écrit :
> >> On Thu, Aug 11, 2011 at 4:55 AM, Brian Curtin <brian.curtin at gmail.com>
> >> wrote:
> >> > Now that we have concurrent.futures, is there any plan for
> >> > multiprocessing to follow suit? PEP 3148 mentions a hope to add or
> move
> >> > things in the future [0], which would be now.
> >>
> >> As Jesse said, moving multiprocessing or threading wholesale was never
> >> part of the plan. The main motivator of that comment in PEP 3148 was
> >> the idea of creating 'concurrent.pool', which would provide a
> >> concurrent worker pool API modelled on multiprocessing.Pool that
> >> supported either threads or processes as the back end, just like the
> >> executor model in concurrent.futures.
> >
> > Executors *are* pools, so I don't know what you're talking about.
>

Also the Pool from multiprocessing "works" for threads and process:

from multiprocessing.pool import Pool as ProcessPool
from multiprocessing.dummy import Pool as ThreadPool
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110811/1acb854b/attachment.html>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2011-August/112798.html below:

[Python-Dev] Moving forward with the concurrent package