Is this optparse object abuse?

[Diez B. Roggisch]

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
> ...
> ?
> 
> 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?

Make function_one and function_two methods of class "State" (you'd obviously
like to rename it something more useful then)

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. 

Passing opaque state objects though is usually not the way to go. There are
a few circumstances where this is justified - for example in very loosely
coupled scenarios where state is passed through layers of otherwise
agnostic code that you don't want to adapt just because some deep-down
piece of code needs a new parameter.

But these occasions really are very rare IMHO.

Diez