On Wed, Aug 10, 2011 at 7:03 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > 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. > > The basic approach is to look at a feature in threading or > multiprocessing that is only available in one of them and ask the > question: Does it make sense to allow a project to switch easily > between a threading strategy and a multiprocessing strategy when using > this feature? > > If the answer to that question is yes (as it was for > concurrent.futures itself, and as I believe it to be for > multiprocessing.Pool), then a feature request (and probably a PEP) > proposing the definition of a common API in the concurrent namespace > would be appropriate. >
Precisely. Thank you Nick, want a job working for PyCon? ;) _______________________________________________ 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
