Announcement

Collapse
No announcement yet.

SNAPpy*from import * Globals

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • SNAPpy*from import * Globals

    In SNAPpy, you are restricted to from import * statements. Unfortunately, in "full" python that means that all globals are copied and not referenced. Example:

    A.py:
    from B import *

    foo = 3
    print(foo)
    print(fooInB())
    bar()
    print(foo)
    print(fooInB())

    B.py:
    foo = 1

    def bar():
    global foo
    foo = 2

    def fooInB():
    return foo

    Output:
    3
    1
    3 # bar() does not change the value in the scope of A!
    2 # bar() only changes it inside the scope of B!

    So in this example, the value of foo from module A differs from the foo in module B, so module B's fooInB() getter and bar() setter functions only apply to the foo variable in module B. So you cannot use those functions to change A.foo

    Now in "full" python you would be able to use 'import B' to set that global in the other module ('B.foo = 3'). But you cannot do this in SNAPpy. Therefore there is no 'good' way to set global variables in other modules. In theory, you could right a bunch of Get-Set wrapper functions, but this gets tedious.

    So my real question is, is it safe to say that SNAPpy REFERENCES all globals when it imports them from other modules (Thus allowing you do do this), or does it COPY them? And if it does copy them is there a workaround for this?
    Last edited by danebouchie; 01-02-2018, 06:27 AM.

  • #2
    In Python, each module has its own independent global namespace.

    In SNAPpy, there is only one namespace, that of the main module. Also, 'module' objects don't exist at runtime, so anything from other modules that weren't imported into the main module won't make it into the compiled script.

    Saying "there is no 'good' way to set global variables in other modules" is not even meaningful, because there is no such thing as "other modules".

    Note that when you have code at the top level (outside of any function), it's actually running in the full Python environment inside Portal, so the normal Python rules apply. Anything that actually runs as part of your script is subject to the SNAPpy limitations.

    Comment


    • #3
      Thanks, that's the exact answer I was looking for!

      Comment

      Working...
      X