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

[Brett Cannon]

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>