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
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