On Fri, Mar 5, 2010 at 9:55 AM, 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. "Future" is a pretty standard CS term for this concept (as noted "promise" is another), and it wasn't invented by Java. I am not worried at all about confusion with __future__ (which is after all surrounded by dunders and only appears in one specific context). FWIW, there are two different ways of designing the API for such a concept. In one, the "future" or "promise" object masquerades as an instance of the eventual result, like a proxy, and accessing any attribute would block until the result is available. I don't like this design much; the masquerading is never perfect, and attribute accesses become risks of exceptions related to the promised work. In the other design, which this PEP proposes, there is an explicit call to get the value, which blocks as needed. I found a wikipedia article (http://en.wikipedia.org/wiki/Futures_and_promises#Implicit_vs_explicit) that calls the former "implicit" and the latter "explicit". According to this article, the term "promise" was coined slightly older (by a year or so). I have no strong preference for either term; I suspect that if this were the only objection to the PEP Brian would be happy to rename futures to promises. -- --Guido van Rossum (python.org/~guido)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4