[petsc-dev] script.py

[Jed Brown]

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