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

exarkun at twistedmatrix.com exarkun at twistedmatrix.com
Fri Mar 5 21:18:22 CET 2010


On 07:10 pm, guido at python.org wrote:
>On Fri, Mar 5, 2010 at 10:30 AM,  <exarkun at twistedmatrix.com> wrote:
>>On 05:06 pm, curt at hagenlocher.org wrote:
>>>
>>>On Fri, Mar 5, 2010 at 8:35 AM, Jesse Noller <jnoller at gmail.com> 
>>>wrote:
>>>>
>>>>On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach
>>>><daniel at stutzbachenterprises.com> wrote:
>>>> > On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan 
>>>><brian at sweetapp.com>
>>>> > wrote:
>>>> >>
>>>> >> import futures
>>>> >
>>>> > +1 on the idea, -1 on the name.  It's too similar to "from 
>>>>__future__
>>>> > import
>>>> > ...".
>>>>
>>>>Futures is a common term for this, and implemented named this in 
>>>>other
>>>>languages. I don't think we should be adopting things that are 
>>>>common,
>>>>and found elsewhere and then renaming them.
>>>
>>>Another common term for this is a "promise".
>>
>>Promises aren't exactly the same.  This would be a particularly bad 
>>name to
>>apply here.
>
>Please explain. Even the Wikipedia article
>(http://en.wikipedia.org/wiki/Futures_and_promises), despite promising
>to explain the difference, didn't explain it.

The "explicit" futures on the wikipedia page seems to cover what is 
commonly referred to as a future.  For example, Java's futures look like 
this.

The "implicit" futures are what is generally called a promise.  For 
example, E's promises look like this.

Though the difference is mainly one of API, it turns out to make a 
significant difference in what you can accomplish.  Promises are much 
more amenable to the pipelining optimization, for example.  They're also 
much harder to implement in Python without core language changes.

Jean-Paul


More information about the Python-Dev mailing list