On Fri, Mar 5, 2010 at 3:31 PM, Brett Cannon <br...@python.org> wrote:
> > So I don't quite get what you are after here. Are you wanting to eventually > have a generic pool class that you can simply import and use that is always > set to the best option for the platform? > And as for moving stuff from multiprocessing into the concurrent namespace, > are you thinking like concurrent.multiprocessing? I guess I am just trying > to figure out what the abstraction is you are after in the package > namespace. > -Brett My goal would be to put futures into a "concurrent" package - as it is an abstraction that allows for threads, and processes to be used. By default; I don't think we'd make a guess based on the platform, but rather pick a sane default (such as threads). After that; I would begin to remove chunks of multiprocessing (such as pool) and adapt it to the same type of "pick threads or processes" that futures uses. For example: from concurrent import Pool x = Pool(4, worker_primitive=Thread()) And so on. The end-goal would be to make concurrent.* a package containing common abstractions/patterns which can use threads or processes interchangeably. jesse _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com