Is this optparse object abuse?

[Diez B. Roggisch]

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

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.



Diez