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