[Python-Dev] [PEP 3148] futures - execute computations asynchronously (original) (raw)

Brett Cannon brett at python.org
Fri Mar 5 21:31:29 CET 2010

On Fri, Mar 5, 2010 at 09:55, Jesse Noller <jnoller at gmail.com> wrote:

On Fri, Mar 5, 2010 at 12:28 PM, Daniel Stutzbach <daniel at stutzbachenterprises.com> wrote: > On Fri, Mar 5, 2010 at 11:03 AM, Jesse Noller <jnoller at gmail.com> wrote: >> >> http://java.sun.com/javase/6/docs/api/java/util/concurrent/Future.html > > According to that link, Java has a module named "Concurrent" with an > interface named "Future". You're proposing a module named "Futures" with a > class named "Future". > > Why not name your module "concurrent"? That would eliminate the confusion > with "from future". I don't see a problem with keeping the class name. > > Plus, a "concurrent" module might be useful for things other than Futures, > in the future. ;-) >

Brian's module is named futures; I am +1'ing his proposal, and also suggesting we put it under concurrent/ package name. This means you would do the following: from concurrent import futures and in the future: from concurrent import pool And so on.

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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20100305/abab7673/attachment.html>

More information about the Python-Dev mailing list