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. 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
