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