Is this optparse object abuse?

[John O'Hagan]

On Sun, 16 Nov 2008, Diez B. Roggisch wrote:
> > 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.
> >
[...]
> >
> > My question is: is this horribly inefficient or otherwise wrong?
>
> Partially, I do the same - passing around the opts-object so that I don't
> have to e.g. pass verbosity-levels around explicit.
>
> *BUT* what I would *never* do is to assign to the options-object! If you
> need state that changes and is something else that configuration, use a
> class and instance-attributes together with self to communicate and alter
> that state. The reason is simply that you don't do it much differently now,
> but the options-object gets a god-like status it shouldn't have. Without
> tracing all calls in the correct order, it is impossible to say what state
> the object might have.

I see your point but I want to be clear on the correct approach: to take my 
original example, is the following better:

class State:
    pass
state = State()
...
def function_two(options, state):
   
    bar =  options.option_two
    state.old_option_two = bar
    bar = bar * foo
    state.new_option_two = bar

def function_three(options, state):
    blop = state.old_option_two
...
?

But don't we have the same problem with keeping track of state? And where 
does "self" come into it (apart from its role in defining a class) if we are 
just using the class as a container? 

Apologies for my obtuseness,

Regards,

John