Class or Dictionary?

[Steven D'Aprano]

On Fri, 11 Feb 2011 16:31:09 -0800, Martin De Kauwe wrote:

> The 100+ parameters just means "everything" can be adjusted outside of
> the code, invariable most of it isn't.

If people aren't going to change all these parameters, why are you 
spending the time and energy writing code for something that won't happen?

There are *real costs* to increasing the amount of customization people 
can do with your code. The more complex your code, the more bugs it will 
contain. You should consider this almost a law of nature.

The more power you give people to change parameters, the more often they 
will hit unexpected interactions between parameters that you never 
imagined. You should expect bug reports that will take forever to track 
down, because (for example) the bug only occurs when param #37 is larger 
than param #45, but only if param #62 is less than param #5 and both are 
less than 100 and param #83 is a multiple of 17...

The more complex your code, the more tests you will need to be sure the 
code does what you expect. The number of combinations that need testing 
*explodes* exponentially. You simply cannot test every combination of 
parameters. Untested code should be considered buggy until proven 
otherwise.

Think very carefully before allowing over-customization. Take into 
account the costs as well as the benefits. Then, if you still decide to 
allow all that customization, at least you know that the pain will be 
worth it.


> As I said I am happy to consider a dictionary, although some of the
> calculations are quite complex and I *think* it is easier to read this
> way, rather than with a dictionary.

I believe that most of these calculations should be written as functions 
which take arguments. This will allow better testing and customization. 
Instead of writing complex calculations inline, you should make them 
functions or methods. There's little difference in complexity between:

my_calculation(arg1, arg2, arg3, params.x, params.y, params.z)

and

my_calculation(arg1, arg2, arg3, params['x'], params['y'], params['z'])

(although, as you have realised, the second is a little more visually 
noisy -- but not that much).

Better still, have the function use sensible default values:

def my_calculation(arg1, arg2, arg3, x=None, y=None, z=None):
    if x is None: 
        x = params.x  # or params['x'], who cares?
    if y is None:
        y = params['y']  # or params.x
    ...


This gives you the best of both worlds: you can supply parameters at 
runtime, for testing or customization, but if you don't, the function 
will use sensible defaults.


> That is purely an opinion, I don't
> have a computer science background and so I am asking really, is what I
> am doing very bad, and if so why? What do other people do? I have tried
> to search a lot on this subject but I find the example not very
> specific, (or I am reading the wrong places).

Whether you use obj.x or obj['x'] is the least important part of the 
problem. That's merely syntax.




-- 
Steven