On Sun, 14 Mar 2010 13:29:57 -0500, Matthew Knepley <knepley at gmail.com> wrote: > Okay, whatever 'yuckiness' is here is imposed on us by the threading > package. I think what is confusing you guys is the reprocessing of > output, since Satish likes it cleaned up. The 'else' branch where > Barry added code is actually the success branch since thread.isAlive() > is false, meaning it completed. We reprocess the output and > return. The status and error have already been set during the run() > call. Its this call that makes us us globals for these variables. Its > the Python equiv of a closure.
You can close over the present scope without using globals. As a crude example, def foo(): x[:] = [4,5,6] # x = [4,5,6] would assign to a new local x = [1,2] foo() # same effect if you create and run a thread here print x # [4,5,6] In the present context, this function is not returned so it is just downward funargs and can be done without proper closures. If you use globals, you don't need anything resembling a closure, and indeed, the run() function in script.py bears no such resemblance. There are several ways to make the 'x' within 'foo' come from the enclosing scope instead of the default which would make it a new local (I find Python scoping rules remarkably surprising). In conclusion, is there a reason why we are currently using globals *instead* of a closure? Jed
