On Sat, Nov 7, 2009 at 9:49 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > >> This is the area where I am most worried. Though multiprocessing is a >> drop in replacement for threading, threading is not currently a drop >> in replacement for multiprocessing. If multiprocessing doesn't make >> sense for Jython and we need to tell our users that they should just >> use threading, threading needs to do everything that multiprocessing >> does... > > Well, feel free to propose a patch for threading.py. > I'm not sure this has anything to do with the discussion about futures > anyway. > > Regards > > Antoine. >
It may smell off topic Antoine - but it fundamentally isn't. Multiprocessing exposes a lot more "goodies" than the threading module. Threading lacks parity (and actually can't have it for some things) with multiprocessing. The futures package actually adds a nice API for a given set of tasks on top of both threading and multiprocessing, and so begs the question "how do alternative implementations which don't have multiprocessing" deal with a new package which offers access to an API of which part builds on multiprocessing. I don't think that question is going to be solved in the context of this particular discussion, given that any solution to that question lacks something Brian's futures package has - working code. On the other hand, possibly pushing futures into a concurrent.* namespace within the standard library means that you could have concurrent.futures, concurrent.map, concurrent.apply and so on, and pull the things which multiprocessing does and threading can as well into that concurrent package. jesse _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
