Is this optparse object abuse?

[John O'Hagan]

On Sun, 16 Nov 2008, Diez B. Roggisch wrote:
> John O'Hagan wrote:
> > 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
> > ...
> > ?
[...]
>
> Make function_one and function_two methods of class "State" (you'd
> obviously like to rename it something more useful then)

That hadn't occurred to me, as the real functions concerned (about a dozen) 
deal with different kinds of objects, it's just the (50+) options (and things 
derived from the options) that they need to share, to varying degrees. I 
guess I had thought of a class as something that deals with a particular type 
of "data". But I see that this is the way to go. 
>
> Options are something that is given by the user. They should be considered
> read-only. Any state that drives your logic should be explicit, and if
> several functions rely on shared state, then a class is the usual answer.
> Alternatively, you can of course pass explicit arguments.
[...]
Thanks for the helpful replies.

Regards,

John