RetroSearch Browse

Fri Mar 5 21:51:59 CET 2010 · https://mail.python.org/pipermail/python-dev/2010-March/098200.html

On Fri, Mar 5, 2010 at 3:31 PM, Brett Cannon <brett at 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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2010-March/098200.html below:

[Python-Dev] [PEP 3148] futures - execute computations asynchronously