On Thu, Aug 11, 2011 at 5:07 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > Le Thu, 11 Aug 2011 09:03:35 +1000, > Nick Coghlan <ncogh...@gmail.com> a écrit : >> On Thu, Aug 11, 2011 at 4:55 AM, Brian Curtin <brian.cur...@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.
Yes, that's the point. A developer shouldn't be forced into using a particular invocation model (i.e. futures) just to get thread or process pool functionality - the pool should be a lower layer building block that's provided separately. As you say, though, nobody has stepped up for the task of actually defining that common, lower level interface. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com