Hello,
I've recently found it convenient to do something like this:
options = optparse_functi on(sys.argv[1:])
##print options =>
##{option_one:4 , option_two:[5, 3, 7, 8, 6], option_three:'/home/files'}
#(Note that this is not a dictionary, even though it looks like one; it's how
#an optparse instance reports what it's holding.)
def function_one(op tions):
foo = options.option_ one
do stuff with foo
def function_two(op tions):
foo = options.option_ one
bar = options.option_ two
options.old_opt ion_two = bar
bar = bar * foo
options.option_ two = bar
def function_three( options):
blop = options.old_opt ion_two
blip = options.option_ three
do stuff with blip and blop
....
In other words, using the optparse object to hold as attributes everything
needed by all the functions and methods in the module, and simply passing it
holus bolus to all them and just pulling out what's actually needed inside
the function, even adding new attributes or reassigning old ones along the
way.
I find it convenient (esp. when there are a lot of options spread over a lot
of functions) because I don't need to fuss about with positional arguments,
keyword dictionaries, default values etc., and it's also easy to pass new or
altered stuff from one function or method to another without polluting the
namespace, as you only get the names out of the object when you assign a name
to the attribute inside a function or method, and vice-versa. And adding
a "feature" to a function is as easy as typing "options.bl ah".
And if this works, why not use a generic object for the same purpose when
options are not involved?
However, before I get too excited: it does seem too easy, and I have no idea
how these objects are implemented - for all I know I'm using a truck to
deliver a ping-pong ball.
My question is: is this horribly inefficient or otherwise wrong?
Thanks,
John O'Hagan
I've recently found it convenient to do something like this:
options = optparse_functi on(sys.argv[1:])
##print options =>
##{option_one:4 , option_two:[5, 3, 7, 8, 6], option_three:'/home/files'}
#(Note that this is not a dictionary, even though it looks like one; it's how
#an optparse instance reports what it's holding.)
def function_one(op tions):
foo = options.option_ one
do stuff with foo
def function_two(op tions):
foo = options.option_ one
bar = options.option_ two
options.old_opt ion_two = bar
bar = bar * foo
options.option_ two = bar
def function_three( options):
blop = options.old_opt ion_two
blip = options.option_ three
do stuff with blip and blop
....
In other words, using the optparse object to hold as attributes everything
needed by all the functions and methods in the module, and simply passing it
holus bolus to all them and just pulling out what's actually needed inside
the function, even adding new attributes or reassigning old ones along the
way.
I find it convenient (esp. when there are a lot of options spread over a lot
of functions) because I don't need to fuss about with positional arguments,
keyword dictionaries, default values etc., and it's also easy to pass new or
altered stuff from one function or method to another without polluting the
namespace, as you only get the names out of the object when you assign a name
to the attribute inside a function or method, and vice-versa. And adding
a "feature" to a function is as easy as typing "options.bl ah".
And if this works, why not use a generic object for the same purpose when
options are not involved?
However, before I get too excited: it does seem too easy, and I have no idea
how these objects are implemented - for all I know I'm using a truck to
deliver a ping-pong ball.
My question is: is this horribly inefficient or otherwise wrong?
Thanks,
John O'Hagan
Comment