Python: Sharing global variables between modules and classes therein
Question:
I know that it’s possible to share a global variable across modules in Python. However, I would like to know the extent to which this is possible and why. For example,
global_mod.py
x = None
mid_access_mod.py
from global_mod import *
class delta:
def __init__(self):
print x
bot_modif_mod.py
import mid_access_mod
import global_mod
class mew:
def __init__(self):
global_mod.x = 5
def main():
m = mew()
d = mid_access_mod.delta()
This prints None, even though all the modules are sharing the global variable x. Why is this the case? It seems like x is evaluated at mid_access_mod.py before it is assigned in bot_modif_mod.py by mew().
Answers:
This happens because you are using immutable values (ints and None), and importing variables is like passing things by value, not passing things by reference.
If you made global_mod.x a list, and manipulated its first element, it would work as you expect.
When you do from global_mod import x, you are creating a name x in your module with the same value as x has in global_mod. For things like functions and classes, this works as you would expect, because people (generally) don’t re-assign to those names later.
As Alex points out, if you use import global_mod, and then global_mod.x, you will avoid the problem. The name you define in your module will be global_mod, which always refers to the module you want, and then using attribute access to get at x will get you the latest value of x.
from whatever import * is not a good idiom to use in your code — it’s intended for use, if ever, in an interactive session as a shortcut to save some typing. It basically “snapshots” all names from the module at that point in time — if you ever rebind any of those names, the snapshot will have grown stale and all sort of problems will ensue. And that’s only the beginning of the inextricable mess you’re signing up for by using the wretched from ... import * construct.
Want my advice? Forget you ever heard about that construct existing and never, ever use it again. Use import global_mod as m and always use thereafter qualified names such as m.x — qualified names are so much handier and more powerful in Python, than mere barenames, that it ain’t even funny. (The as m part of the import statement is totally optional and basically exists for conciseness purposes, or sometimes to work around some issues with name clashes; use it when and if you find it handy, since it has no downsides, but don’t feel forced or even urged to use if when you don’t feel it’s necessary).
I modified the example to use a list for x, and list assigns (x[0] = ..) as suggested in the top answer, and the print returned the same initial value (None)..This verifies that the “from global_mod import *” is a copy regardless of mutable or not.
As suggested in the comment “import global_mod” works, if “print global_mod.x = is then used in mid_access_mod.
As Ned Batchelder mentioned, only the values are shared and not the actual object. If you want to share an object by reference, then you are probably looking Thread-Local Data.
Eg:
import threading
g = threading.local()
g.population = '7 Billion'
Now, whenever you want to access or change the variable g.population, you will get an updated value of it, provided it is the same thread you are trying to access it from.
Read more in the Python documentation:https://docs.python.org/3/library/threading.html#thread-local-data
To solve this problem, just change from global_mod import * to import global_mod.
And the new mid_access_mod.py will be:
import global_mod
class delta:
def __init__(self):
print global_mod.x
The reason for that could be found here.
Due to the way references and name binding works in Python, if you want to update some symbol in a module, say foo.bar, from outside that module, and have other importing code “see” that change, you have to import foo a certain way.
I know that it’s possible to share a global variable across modules in Python. However, I would like to know the extent to which this is possible and why. For example,
global_mod.py
x = None
mid_access_mod.py
from global_mod import *
class delta:
def __init__(self):
print x
bot_modif_mod.py
import mid_access_mod
import global_mod
class mew:
def __init__(self):
global_mod.x = 5
def main():
m = mew()
d = mid_access_mod.delta()
This prints None, even though all the modules are sharing the global variable x. Why is this the case? It seems like x is evaluated at mid_access_mod.py before it is assigned in bot_modif_mod.py by mew().
This happens because you are using immutable values (ints and None), and importing variables is like passing things by value, not passing things by reference.
If you made global_mod.x a list, and manipulated its first element, it would work as you expect.
When you do from global_mod import x, you are creating a name x in your module with the same value as x has in global_mod. For things like functions and classes, this works as you would expect, because people (generally) don’t re-assign to those names later.
As Alex points out, if you use import global_mod, and then global_mod.x, you will avoid the problem. The name you define in your module will be global_mod, which always refers to the module you want, and then using attribute access to get at x will get you the latest value of x.
from whatever import * is not a good idiom to use in your code — it’s intended for use, if ever, in an interactive session as a shortcut to save some typing. It basically “snapshots” all names from the module at that point in time — if you ever rebind any of those names, the snapshot will have grown stale and all sort of problems will ensue. And that’s only the beginning of the inextricable mess you’re signing up for by using the wretched from ... import * construct.
Want my advice? Forget you ever heard about that construct existing and never, ever use it again. Use import global_mod as m and always use thereafter qualified names such as m.x — qualified names are so much handier and more powerful in Python, than mere barenames, that it ain’t even funny. (The as m part of the import statement is totally optional and basically exists for conciseness purposes, or sometimes to work around some issues with name clashes; use it when and if you find it handy, since it has no downsides, but don’t feel forced or even urged to use if when you don’t feel it’s necessary).
I modified the example to use a list for x, and list assigns (x[0] = ..) as suggested in the top answer, and the print returned the same initial value (None)..This verifies that the “from global_mod import *” is a copy regardless of mutable or not.
As suggested in the comment “import global_mod” works, if “print global_mod.x = is then used in mid_access_mod.
As Ned Batchelder mentioned, only the values are shared and not the actual object. If you want to share an object by reference, then you are probably looking Thread-Local Data.
Eg:
import threading
g = threading.local()
g.population = '7 Billion'
Now, whenever you want to access or change the variable g.population, you will get an updated value of it, provided it is the same thread you are trying to access it from.
Read more in the Python documentation:https://docs.python.org/3/library/threading.html#thread-local-data
To solve this problem, just change from global_mod import * to import global_mod.
And the new mid_access_mod.py will be:
import global_mod
class delta:
def __init__(self):
print global_mod.x
The reason for that could be found here.
Due to the way references and name binding works in Python, if you want to update some symbol in a module, say foo.bar, from outside that module, and have other importing code “see” that change, you have to import foo a certain way.