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
--
http://mail.python.org/mailman/listinfo/python-list
