Hello, I've recently found it convenient to do something like this:
options = optparse_function(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(options): foo = options.option_one do stuff with foo def function_two(options): foo = options.option_one bar = options.option_two options.old_option_two = bar bar = bar * foo options.option_two = bar def function_three(options): blop = options.old_option_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.blah". 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 -- http://mail.python.org/mailman/listinfo/python-list