[Python-Dev] Moving forward with the concurrent package

Jesse Noller jnoller at gmail.com
Wed Aug 10 23:34:42 CEST 2011


On Wed, Aug 10, 2011 at 4:45 PM, Brian Curtin <brian.curtin at gmail.com> wrote:
> On Wed, Aug 10, 2011 at 15:36, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>
>> Le Wed, 10 Aug 2011 14:54:33 -0500,
>> Benjamin Peterson <benjamin at python.org> a écrit :
>> > 2011/8/10 Brian Curtin <brian.curtin at gmail.com>:
>> > > 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
>> >
>> > Is there some sort of concrete proposal? The PEP just seems to mention
>> > it as an idea.
>> >
>> > In general, -1. I think we don't need to be moving things around more
>> > to little advantage.
>>
>> Agreed. Also, flat is better than nested. Whoever wants to populate the
>> concurrent package should work on new features to be added to it, rather
>> than plans to rename things around.
>
> I agree with flat being better than nested and won't be pushing to move
> things around, but the creation of the concurrent package seemed like a
> place to put those things. I just found myself typing
> "concurrent.multiprocessing" a minute ago, so I figured I'd put it out
> there.

I would like to move certain *features* of multiprocessing into that
namespace - some things like map and others don't belong in the
multiprocessing namespace, and should have been put into concurrent.*
a long time ago.

As for my plans: I had intended on making multiprocessing a closer
corollary to threading, and moving the bigger features that should
have been broken out into a different package (such as
http://bugs.python.org/issue12708) and the managers.

Those plans are obviously stalled as my time is being spent elsewhere.
I disagree on the "flat is better than nested" point -
multiprocessing's namespace is flat - but bloated, and many of it's
features could work just as well in a threaded context (e.g, they are
generally useful outside of multiprocessing alone).

Regardless; currently I can't lead this, and multiprocessing-sig is silent.

Jesse


More information about the Python-Dev mailing list