By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
439,986 Members | 1,583 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 439,986 IT Pros & Developers. It's quick & easy.

Another software design question: program-level globals

P: n/a
OK, here's another software design question, one that's been bugging me
for a while now. What do y'all think is the best way to handle
program-level globals, such as configuration option -- especially in
multi-module programs?

Here's one approach:

--- main.py ---
import my_globals as g
import somefuncs
import morefuncs
from optparse import OptionParser

def main():
parser = OptionParser()
parser.add_option( ... )
g.opts, g.args = parser.parse_args()

somefuncs.do_setup()
morefuncs.do_some_more_setup()

somefuncs.do_some_work()

if __name__ == '__main__':
main()
--- somefuncs.py ---
import my_globals as g

def do_setup():
if g.opts.some_option:
do_it_one_way()
else:
do_it_a_different_way()
--- morefuncs.py ---
import my_globals as g

def do_some_more_setup():
for arg in g.args:
do_something_with(arg)
--- my_globals.py ---
(empty file)
This approach relies on the fact that modules only get imported once.
Thus when each module imports my_globals, it gets the *same* object
(which is then given the name g to make it easier to write later). So
when the attributes of g are modified in the main() function, they can
then be read by do_setup() and do_some_more_setup(), because the object
that somefuncs.py and morefuncs.py call "g" is the same module object
that main.py also calls "g".

This is the best approach I've found so far, but I would welcome
comments and suggestions for improvements.

--
Robin Munn
rm***@pobox.com
Jul 18 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
On Fri, 13 Feb 2004 18:43:54 GMT, Robin Munn wrote:
OK, here's another software design question, one that's been bugging
me for a while now. What do y'all think is the best way to handle
program-level globals, such as configuration option -- especially in
multi-module programs?


The first thing to do is: don't use globals. The interface between
disparate parts of your code (functions, classes, modules, packages)
should be as explicit and discoverable as possible.

Often the simplest first step in eliminating globals is to wrap them up
in a class (such as ConfigOptions) as class attributes. Other, more
elegant solutions may require refactoring the code.

--
\ "I like to go to art museums and name the untitled paintings. |
`\ 'Boy With Pail'. 'Kitten On Fire'." -- Steven Wright |
_o__) |
Ben Finney <http://bignose.squidly.org/>
Jul 18 '05 #2

P: n/a
"Robin Munn" <rm***@pobox.com> wrote in message
news:KV****************@newssvr26.news.prodigy.com ...
OK, here's another software design question, one that's been bugging me
for a while now. What do y'all think is the best way to handle
program-level globals, such as configuration option -- especially in
multi-module programs?
You've basically got it: modules are inherently singletons.
I would, of course, dress up your solution by putting the
configuration reader and so forth into a class, and possibly
putting that behind some kind of proxy so I could easily
slide in mock objects for testing.

John Roth
--
Robin Munn
rm***@pobox.com

Jul 18 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.