global variables in imported modules

V

vsoler

Taken from www.python.org, FAQ 2.3 How do I share global variables
across modules?

config.py:

x = 0 # Default value of the 'x' configuration setting


mod.py:

import config
config.x = 1


main.py:

import config # try removing it
import mod
print config.x

The example, such as shown in the website, works perfectly well.
However, I don't fully understand why I have to import config in
main.py, since it has already been imported by mod.py.

As the website explains, there is only one module namespace for each
module, and mod.py has aleady created the config namespace by
importing it. Why should I import it again in main.py if that
namespace already exists?

If I remove -> import config # try removing it in main.py,
the application does not run

What am I missing?
 
P

Patrick Maupin

Taken fromwww.python.org, FAQ 2.3 How do I share global variables
across modules?

config.py:

x = 0   # Default value of the 'x' configuration setting

mod.py:

import config
config.x = 1

main.py:

import config       # try removing it
import mod
print config.x

The example, such as shown in the website, works perfectly well.
However, I don't fully understand why I have to import config in
main.py, since it has already been imported by mod.py.

As the website explains, there is only one module namespace for each
module, and mod.py has aleady created the config namespace by
importing it. Why should I import it again in main.py if that
namespace already exists?

If I remove ->   import config       # try removing it     in main.py,
the application does not run

What am I missing?

What you are missing is that the interpreter has to look *inside* a
namespace in order to actually find the object associated with a
name. As you found out, there is a namespace per module. So
main.py's namespace is where the code in main.py will search for
variables. If 'mod' imports config, then the 'mod' module's namespace
is updated with 'config' -> the config module. But the act of 'mod'
importing 'config' will not alter the namespace of 'main' at all. So
if you want to access variable 'x' inside 'config' from main you can
either import config directly into main and access it as config.x, or
you can import config into mod and import mod into main and access it
as mod.config.x.

Regards,
Pat
 
V

vsoler

What you are missing is that the interpreter has to look *inside* a
namespace in order to actually find the object associated with a
name.  As you found out, there is a namespace per module.  So
main.py's namespace is where the code in main.py will search for
variables.  If 'mod' imports config, then the 'mod' module's namespace
is updated with 'config' -> the config module.  But the act of 'mod'
importing 'config' will not alter the namespace of 'main' at all.  So
if you want to access variable 'x' inside 'config' from main you can
either import config directly into main and access it as config.x, or
you can import config into mod and import mod into main and access it
as mod.config.x.

Regards,
Pat

Thank you Pat, it's very clear.

However, can I be 100% sure that,no matter how I access variable
'x' (with config.x or mod.config.x) it is always the same 'x'. I mean
that either reference of 'x' points to the same id(memory position)?

Thank you
 
J

James Mills

However, can I be 100% sure that,no matter how I access variable
'x' (with config.x or mod.config.x) it is always the same 'x'. I mean
that either reference of 'x' points to the same id(memory position)?

Yes it does unless you re-assign it.

--James
 
P

Patrick Maupin

Yes it does unless you re-assign it.

--James


To expand a bit on what James is saying:

If, for example, inside your main module, you got tired of typing
"mod.config.x" everywhere you were using it, and decided that you
could make a local reference to the same variable:

x = mod.config.x

Now, whenever you use just plain x inside the main module, you are
also referencing the exact same object, *until* some other function
decides to do:

mod.config.x = y

At this point in time, the 'x' inside main references the object that
mod.config.x originally referenced, but mod.config.x now references a
different object.

Unlike C, for example, where the assignment operator physically places
an item into a specific memory location (either fixed globally or
within a stack frame), the assignment operator in python simply stores
a key/value pair into a namespace dictionary. So whenever you
retrieve a value from the dictionary using that key, you will get the
value that was last associated with that key.

So, 'mod.config.x' will first retrieve the object associated with the
key 'mod' from the main module's namespace dictionary, then will
retrieve the object associated with the key 'config' from that
module's namespace dictionary, then will retrieve the object
associated with the key 'x' from that module's namespace dictionary.
Unless you later modify any of those key/value pairs, subsequent
retrieval will always result in the same final value.

Regards,
Pat
 
V

vsoler

To expand a bit on what James is saying:

If, for example, inside your main module, you got tired of typing
"mod.config.x" everywhere you were using it, and decided that you
could make a local reference to the same variable:

x = mod.config.x

Now, whenever you use just plain x inside the main module, you are
also referencing the exact same object, *until* some other function
decides to do:

mod.config.x = y

At this point in time, the 'x' inside main references the object that
mod.config.x originally referenced, but mod.config.x now references a
different object.

Unlike C, for example, where the assignment operator physically places
an item into a specific memory location (either fixed globally or
within a stack frame), the assignment operator in python simply stores
a key/value pair into a namespace dictionary.  So whenever you
retrieve a value from the dictionary using that key, you will get the
value that was last associated with that key.

So, 'mod.config.x' will first retrieve the object associated with the
key 'mod' from the main module's namespace dictionary, then will
retrieve the object associated with the key 'config' from that
module's namespace dictionary, then will retrieve the object
associated with the key 'x' from that module's namespace dictionary.
Unless you later modify any of those key/value pairs, subsequent
retrieval will always result in the same final value.

Regards,
Pat

Really interesting, it helps a lot.

Thank you
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,968
Messages
2,570,153
Members
46,699
Latest member
AnneRosen

Latest Threads

Top