Sorry about the html - did not realise. Thanks for your comments. John On 11 Sep 2013, at 22:49, John Pote <johnhp...@o2.co.uk> 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 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). > > 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? > > 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. > > 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 not 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. > > Regards all, > John > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
