3 ms·

I am new to this. Can you give me any pointers to differences between promises and deferreds. I have some idea about promises in JS. http://promises-aplus.githu

I am new to this. Can you give me any pointers to differences between promises and deferreds. I have some idea about promises in JS. http://promises-aplus.github.io/promises-spec/ http://promises-aplus.github.io/promises-spec/ How is twisted's deferred different?

thristian 13y ago
Just the first difference that caught my eye: section 3.1 of the document you linked to says that once fulfilled or rejected, a Promise must not change to any other state, and its value may not change. In Guido's exposition of Deferreds, under the heading "Idea 2: Pass results from callback to callback", he says: The most interesting bits are the last two lines: the result of each callback is passed to the next. This is different from how things work in concurrent.futures and Tulip, where the result (once set) is fixed as an attribute of the Future. Here the result can be modified by each callback. This enables a new pattern when one function returning a Deferred calls another one and transforms its result, and this is what earns this idea three stars.
noelwelsh 13y ago
I think this distinction should be framed in terms of Python's futures, not futures per se. Python's futures (http://docs.python.org/dev/library/concurrent.futures.html#concurrent.futures.Future http://docs.python.org/dev/library/concurrent.futures.html#c...) are very limited. They lack the equivalent of the then method in Javascript promises. This means there is very limited ability to compose futures in Python. Twisted's Deferred allow some kind of composition, though IMHO it is rather messy. You'll note in Guido's emails he says Python's futures are based on Java's. Java's futures (I can say from experience) are a completely useless crock. All you can do is poll them, which makes the whole point of asynchronous operation moot (http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/Future.html http://docs.oracle.com/javase/6/docs/api/java/util/concurren...) Javascript's promises are a better implementation, as are those in Scala and Haskell.

thristian 13y ago

Just the first difference that caught my eye: section 3.1 of the document you linked to says that once fulfilled or rejected, a Promise must not change to any other state, and its value may not change. In Guido's exposition of Deferreds, under the heading "Idea 2: Pass results from callback to callback", he says: The most interesting bits are the last two lines: the result of each callback is passed to the next. This is different from how things work in concurrent.futures and Tulip, where the result (once set) is fixed as an attribute of the Future. Here the result can be modified by each callback. This enables a new pattern when one function returning a Deferred calls another one and transforms its result, and this is what earns this idea three stars.

noelwelsh 13y ago

I think this distinction should be framed in terms of Python's futures, not futures per se. Python's futures (http://docs.python.org/dev/library/concurrent.futures.html#concurrent.futures.Future http://docs.python.org/dev/library/concurrent.futures.html#c...) are very limited. They lack the equivalent of the then method in Javascript promises. This means there is very limited ability to compose futures in Python. Twisted's Deferred allow some kind of composition, though IMHO it is rather messy. You'll note in Guido's emails he says Python's futures are based on Java's. Java's futures (I can say from experience) are a completely useless crock. All you can do is poll them, which makes the whole point of asynchronous operation moot (http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/Future.html http://docs.oracle.com/javase/6/docs/api/java/util/concurren...) Javascript's promises are a better implementation, as are those in Scala and Haskell.