[Python-Dev] Moving forward with the concurrent package

[Nick Coghlan]

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