Class or Dictionary?
steve+comp.lang.python at pearwood.info
Sat Feb 12 03:11:49 CET 2011
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
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
> 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)
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.
More information about the Python-list