handling many default values

[George Sakkis]

Ben Finney wrote:

> "Alan Isaac" <aisaac at american.edu> writes:
>
> > There are *many* parameters, and the list can change, so I want to
> > avoid listing them all in the Param class's __init__ function, using
> > the strategy above.
> >
> > Q1: Is this approach reasonable?
> >     (This is a newbie question about unforseen hazards.)
> > Q2: Is it horrible design to isolate the parameters in a separate class?
> >     (Comment: currently several classes may rely on (parts of) the same
> > parameter set.)
>
> It's a bad design smell to have functions that accept large numbers of
> parameters, many of them optional. Such an interface is difficult to
> document, maintain and test.
>
> You should certainly be examining such code and seeing how much of it
> can be implemented instead as functions with small, well-defined
> parameter lists. This may mean writing more functions, or more layers
> of functions, or more classes, or whatever; but having a result that
> uses small, well-defined interfaces is a valuable property.

So I guess you prefer the (os.system, os.spawn*, os.popen*, popen2.*,
commands.*) kitchen sink than the single versatile subprocess.Popen
class, right ? I respectfully disagree, and I'm all for
one-class-does-it-all, as long as most parameters are optional and the
default values address the most typical/reasonable case.

To answer to OP's question, your approach is totally reasonable and
well-known; the csv.Dialect class for example is exactly this, a
parameter-holding class.

George