Is this optparse object abuse?

[John O'Hagan]

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