RetroSearch Browse

Thu Aug 11 01:06:36 CEST 2011 · https://mail.python.org/pipermail/python-dev/2011-August/112791.html

On Wed, Aug 10, 2011 at 7:03 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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.
>
> 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? ;)

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2011-August/112791.html below:

[Python-Dev] Moving forward with the concurrent package