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

pass data from optparse to other class instances

P: n/a
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
Jun 27 '08 #1
Share this Question
Share on Google+
2 Replies


P: n/a
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
Jun 27 '08 #2

P: n/a
On Jun 9, 5:42*pm, "Diez B. Roggisch" <de...@nospam.web.dewrote:
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
Jun 27 '08 #3

This discussion thread is closed

Replies have been disabled for this discussion.