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. Besides, multiprocessing.Pool is quite bloated and therefore difficult to improve. It should be slowly phased out in favour of concurrent.futures. In general, it would be nice if people wanting to improve the concurrent primitives made actual, concrete propositions. We've had lots of hand-waving in that area for years, to no effect. Regards Antoine. _______________________________________________ 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
