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

[Guido van Rossum]

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)