On Wed, Aug 10, 2011 at 4:45 PM, Brian Curtin <brian.curtin@gmail.com> wrote:
On Wed, Aug 10, 2011 at 15:36, Antoine Pitrou <solipsis@pitrou.net> wrote:
Le Wed, 10 Aug 2011 14:54:33 -0500, Benjamin Peterson <benjamin@python.org> a écrit :
2011/8/10 Brian Curtin <brian.curtin@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