module variable scope

[Stefan Quandt]

I want to set a modules global variable from outside like this:

<begin a.py>
v = None

def setv( x ): v = x
def getv(): return v
<end a.py>

<begin b.py>
from a import v, setv, getv

print v
setv( 'hello' )
print print getv()
<end b.py>
Running b.py gives:
None
None

I expected variable v to be changed by calling setv() but it is not.
Who can explain this?

Thanks
Stefan

[Alex Martelli]

Stefan Quandt wrote:
...

<begin b.py>
from a import v, setv, getv
The from statement takes a "snapshot" at that instant of time of
the values currently bound to those names in the other module,
binding each value to the same name in the current module.

That's all. It establishes no magical "persistent linkage
between names in different modules" -- there exists no concept
of such magical persistent linkage in Python.

Any rebinding of those or other names in the other module in
the future will be totally irrelevant to the binding of said
names in the current module.

I expected variable v to be changed by calling setv() but it is not.
Who can explain this?

Who can explain your expectations, I dunno. I hope the
explanation of the behavior was clear.

My often-repeated recommendation is: forget the from statement's
very existence. Use

import b

and refer to b.v -- NOT to bare v -- and THEN everything will work
according to expectations.

The 'from' statement is occasionally a handy shortcut if you
know what you're doing, but it doesn't work well when you're
not sure what you're doing, nor when any name rebinding or
module reloading may be involved. That's three strikes
against it, which means _it's out_:-).

The 'import' statement has basically no counter-indications.
If a module's name is long so it gets weary writing
theothermodule.v all the time, use the 'as' clause of import:

import theothermodule as t

and happily refer to t.v -- just 2 characters longer than
barename v, AND with other advantages (immediate clarity of
where the name comes from) as well as avoiding surprises.
Alex

[Dennis Lee Bieber]

Stefan Quandt fed this fish to the penguins on Tuesday 28 October 2003
05:37 am:

I want to set a modules global variable from outside like this:

<begin a.py>
v = None

def setv( x ): v = x
Problem #1... this /v/ is LOCAL to setv(). You need

def setv(x):
global v
v = x
def getv(): return v
<end a.py>

<begin b.py>
from a import v, setv, getv
Problem #2... from <> import <> is /evil/

What you have done is make new /local/ labels for the objects named.

Fixing problem #1 will result in the label "a.v" being moved to the
object containing "x". NOTE: the LABEL moved... "b.v" is not moved,
only "a.v".

-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Bestiaria Home Page: http://www.beastie.dm.net/ <
Home Page: http://www.dm.net/~wulfraed/ <

[Stefan Quandt]

Alex Martelli <al***@aleax.it> wrote in message news:<8t***********************@news2.tin.it>...

Stefan Quandt wrote:
...

<begin b.py>
from a import v, setv, getv

The from statement takes a "snapshot" at that instant of time of
the values currently bound to those names in the other module,
binding each value to the same name in the current module.

That's all. It establishes no magical "persistent linkage
between names in different modules" -- there exists no concept
of such magical persistent linkage in Python.

Any rebinding of those or other names in the other module in
the future will be totally irrelevant to the binding of said
names in the current module.

Oh, I thought that 'from' is a means to explicitly import selected
symbols from a module instead of importing the whole.
I never was aware of the different semantics of using 'from' in
imports.
In this case python does not work like one would intuitively expect.

Of course one could find a hint in the reference manual 6.12:
The from form does not bind the module name: it goes through the list
of identifiers, looks each one of them up in the module found in step
(1), and binds the name in the local namespace to the object thus
found.

Thanks
Stefan