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. 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 | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4