pass data from optparse to other class instances

Tim Arnold a_jtim at bellsouth.net
Tue Jun 10 19:07:08 EDT 2008


On Jun 9, 5:42 pm, "Diez B. Roggisch" <de... at nospam.web.de> wrote:
> Tim Arnold schrieb:
>
>
>
> > 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

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





More information about the Python-list mailing list