pass data from optparse to other class instances

[Tim Arnold]

Hi,
I'm writing a command-line interface using optparse. The cli takes
several options with a single action and several parameters to be used
in the resulting worker classes.

I've been passing parameters from optparse to the workers in two ways:
(1) creating a Globals.py module, set parameters once in the cli code
and read it
when needed in the worker class methods. Something like this:
import Globals
class Foo(object):
def __init__(self):
if Globals.debug:
etc
(2) passing a parameter directly to the worker class __init__ method:
class Bar(object):
def __init__(self, verbose=False):
etc

Are those methods the best/only ways to pass these parameters around?
What's the smart way to do it?
thanks,
--Tim

 

[Diez B. Roggisch]

Hi,
I'm writing a command-line interface using optparse. The cli takes
several options with a single action and several parameters to be used
in the resulting worker classes.

I've been passing parameters from optparse to the workers in two ways:
(1) creating a Globals.py module, set parameters once in the cli code
and read it
when needed in the worker class methods. Something like this:
import Globals
class Foo(object):
def __init__(self):
if Globals.debug:
etc
(2) passing a parameter directly to the worker class __init__ method:
class Bar(object):
def __init__(self, verbose=False):
etc

Are those methods the best/only ways to pass these parameters around?
What's the smart way to do it?

Essentially these are the two ways - and there is not "the" way. Both
approaches are reasonable.

Generally it is better to refuse the temptation to work with global
state - becaues only that ensures that code is de-coupled and more
responsible regarding state.

However there is no need to jump through overly high mounted hoops to
reach that - especially when config-options affect overall program
behaviour, such as verbosity.

So - no clear answer, sorry

Diez

 

[Tim Arnold]

Tim Arnold schrieb:






Essentially these are the two ways - and there is not "the" way. Both
approaches are reasonable.

Generally it is better to refuse the temptation to work with global
state - becaues only that ensures that code is de-coupled and more
responsible regarding state.

However there is no need to jump through overly high mounted hoops to
reach that - especially when config-options affect overall program
behaviour, such as verbosity.

So - no clear answer, sorry

Diez

Thanks for this info. I'm glad to know my thought process is on the
right track. What if I put all this (optparse, worker classes)
together into a package: I guess then could I have my globals set in
the __init__.py.

Which doesn't buy me that much over just importing Globals.py does it.
I kind-of understand about avoiding globals -- your comment about
coupling helped me understand it more. If I put my often used
functions and some global vars in __init__.py, is that any better than
importing them explicitly from Globals.py?
thanks again,
--Tim