syrusakbary
commented
8 years ago Hi @qbolec the error you are describing have to do with the locals in python more than the promise implementation.
The following example will work:
import concurrent.futures
import time
executor = concurrent.futures.ThreadPoolExecutor(max_workers=40000);
from promise import Promise
def identity(x):
time.sleep(1)
return x
def promise_something(x):
return Promise.promisify(executor.submit(identity,x));
print Promise.all([ promise_something(x).then((lambda x:lambda result: result*x)(x)) for x in [0,1,2,3]]).get()This example is encapsulating the x in a new function, so doesn't get overwritten when the next item in the loop is accessed.
qbolec
LivInTheLookingGlass
It seems to me that current implementation is non-compliant with https://promisesaplus.com/ spec with regard to
This manifests in inconsistencies between situations where Promise is resolved immediately (such us during unit-testing with mock data) vs situations where it resolves asynchronously after a while, leading to some bugs in implementation manifesting only after deploying to production.
Consider following toy program with a subtle bug:
It is supposed to produce sequence of squares, and indeed when run, it prints:
But there is a bug lurking in the implementation: the
xvariable used in list comprehension is bound by reference to the closure oflambda: result*x, not by value, so the code works only because the lambda passed tothen()is called synchronously and the current value ofxis used. If however, you uncomment thetime.sleep(1)line, you will get a different output:This time, the same value of
x, namely3was used for all invocations of the lambda, because that was the value variablexretained after iterating over whole array[0,1,2,3].This is just a toy example, but the more complicated version of the same bug occurred in real life scenario to me in code like this:
and it took me a while to figure out what was wrong, as the problem manifested half the time only (namely when run on a clean working directory, without cached results - in case when I already had some cached results on the disk, the Promise returned immediately masking the bug).
Once again: there is a bug in my program, and I know it. But then there is also the Promieses/A+ spec which clearly states, that the callback should not be called before the current stack completes, which I believe leads to more consistent behavior. The README.md of this project proudly claims "Its fully compatible with the Promises/A+ spec", so I think it is a bug in the implementation of this library.