On Fri, Mar 5, 2010 at 09:55, Jesse Noller <jnol...@gmail.com> wrote:
> On Fri, Mar 5, 2010 at 12:28 PM, Daniel Stutzbach > <dan...@stutzbachenterprises.com> wrote: > > On Fri, Mar 5, 2010 at 11:03 AM, Jesse Noller <jnol...@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
_______________________________________________ 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
