global variable across modules

Wed Sep 11 18:15:16 EDT 2013

On 11/9/2013 17:49, John Pote wrote:

> Chris,
> Interesting. 
>> 
>> # Test1.py
>> Debug_Value = " "
>> 
>> # Test2.py
>> from Test1 import *
>> # is exactly equivalent to
>> Debug_Value = " "
>> 
> I take it then that assigning to Debug_Value in Test2.py will not change the value of Debug_Value in Test1.py.

That's correct.  But it would be clearer to say that binding a new
object to Debug_Value in Test2.py after Test1.py has already done its
import does not change the binding that Test1.py has for Debug_Value.

Note that if the object was mutable (which string is not), then it would
be possible to change the object.  In that case, both names would refer
to the new value of the object.

>
> That being the case it would be wrong to assume that the following are identical
>
> import sys
>
> and
>
> from sys import *
>
> (the latter being a convenience  to avoid having to write sys. before every variable).

Right, they're not even close.

>
> Thus assigning to sys.stdout would change the standard out destination in every module importing sys whereas
>
> from sys import *
> stdout = foo.dst
>
> would only change stdout in the current module and sys.stdout would remain unchanged.
>
> Is my understanding here correct?

Yes.  But notice that when you do print() in any module, it indirectly
refers to sys.stdout, even if you have changed your own module's stdout.

>
> <html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Chris,<div>Interesting. <br><div><blockquote type="cite"><br># Test1.py<br>Debug_Value = " "<br><br># Test2.py<br>from Test1 import *<br># is exactly equivalent to<br>Debug_Value = " "<br><br></blockquote></div>I take it then that assigning to Debug_Value in Test2.py will not change the value of Debug_Value in Test1.py.</div><div><br></div><div>That being the case it would be wrong to assume that the following are identical</div><div><br></div><div>import sys</div><div><br></div><div>and</div><div><br></div><div>from sys import *</div><div><br></div><div>(the latter being a convenience  to avoid having to write sys. before every variable).</div><div><br></div><div>Thus assigning to sys.stdout would change the standard out destination in every module importing sys whereas</div><div><br></div><div>from sys import *</div><div>stdout = foo.dst</div><div><br></div><div>would only change stdout in the current module and sys.stdout would remain unchanged.</div><div><br></div><div>Is my understanding here correct?</div><div><br></div><div>As to global usage I do find it useful to have a file called something like 'preferences.py' and put in there constants to be used throughout the application. But I use these strictly read only. It is good in that system wide constants are defined in one place only. Also if the constants are put inside a class, possibly with getter methods, instantiated as a singleton then initially the values can be typed directly into the preferences file. Later the constructor could be changed to read the constants from an initialisation file of your own format (e.g. .ini or JSON). Thus users without python experience might find it easier to change them without having to look at any python code. On the other hand I appreciate simple constant assignments should be easy enough to change without needing to know any Python.</div><div><br></div><div>Also remember that accessing any form of global that is shared between multiple threads is a recipe for disaster unless appropriate locks are used. A significant advantage of <i>not</i> using globals (except for system wide constants) is that is makes testing of individual modules easier. The less coupling there is between modules the easier it is to understand and test.</div><div><br></div><div>Regards all,</div><div>John</div></body></html>
>
>
Try fixing your email program to use text, not html.  This time it's
just wasted space in each copy of the message (where space is money). 
But next time it might lead to indentation problems and other
miscommunication.

-- 
DaveA