Keepin constants, configuration values, etc. in Python - dedicated module or what?

[cl at isbd.net]

Dave Angel <davea at davea.name> wrote:
> cl at isbd.net Wrote in message:
> > I am puzzling where and how to keep these configuration values. My
> > current design has them in dedicated tables in the database but this
> > is rather clumsy in many ways as there's an overhead reading them
> > every time the program needs them and changing them isn't particularly
> > convenient at the Beaglebone doesn't have a GUI so it has to be done
> > using SQL from the command line.
> 
> It is very useful for the database to be self contained and self
>  describing.  Among other things it means that you can easily take
>  a snapshot at any time,  and that snapshot is not tied to any
>  specific version of the code. As for changing with sql, you can
>  always add a configuration utility when using sql becomes a
>  nuisance,  or introduces errors. 
> 
I guess I can write a script to do the change but it's more code to
write and maintain as opposed to simply editing a configuration file
with tools I know well.


> The key thing is to manage change.  You need to decide which
>  things are conceivably going to change and how you'll manage both
>  the change itself and the inevitable split between prechange data
>  and post. One kind of change might be fixing the spelling of
>  battery.  No biggie,  just let new accesses get the new one. 
>  Another kind might be the addition of a new instance of an adc
>  converter.  Not a problem,  as long as you don't reuse an old
>  name. And presumably you never remove an old name from the
>  config.
> 
The only things really likely to change (and may change regularly) are
the conversion factors, drifting voltage references etc. will
inevitably require these to be recalibrated every so often.  Other
than that it's just typos or me deciding to change the name of
something.


> More troublesome is adding a new kind of data. You have to decide
>  whether it's worth generalizing the code to anticipate the
>  change,  or just admit that the code will grow at that point and
>  that old code won't deal with the new data. 
> 
There's a separate module for each input type (just ADC and 1-wire at
the moment), I don't anticipate any more though I suppose there might
be digital inputs one day.  So a configuration [file] for each type
seems to make sense, generalising it would be more trouble than it's
worth I think.


> > 
> > Does it make sense to add them to the modules which handle the reading
> > of the inputs?  I already have modules defining classes called Adc and
> > OneWire, is it a reasonable approach to add the configuration to these
> > as, probably, dictionaries?  Modifying it would be pretty simple -
> > just edit the python source (one of the easiest things for me to do on
> > the Beaglebone as my sole access is via ssh/command line).
> > 
> 
> Nope, read it from the db. You still might be loading it to a cfg
>  variable, however. 
> 
> > Thus I'd have something like (apologies for any syntax errors):-
> > 
> > cfg = { "LeisureVolts": ["AIN0", 0.061256, "Leisure Battery Voltage"],
> >         "StarterVolts": ["AIN1", 0.060943, "Starter Battery Voltage"],
> >         "LeisureAmps1": ["AIN2", 0.423122, "Leisure Battery Current"}
> > 
> > (It might be better to makes those lists dictionaries, but it shows
> > the idea)
> 
> Actually it's probably better to use named tuples. All those lists
>  are apparently of identical length with identical meaning of a
>  given element offset.  But if named tuple isn't flexible,enough, 
>  you probably need a new class.
> 
> > 
> > Are there any better ways of doing this?  E.g. some sort of standard
> > configuration file format that Python knows about?  I would actually
> > quite like to keep the configuration data separate from the code as it
> > would simplify using the data at the 'home' end of things as I'd just
> > need to copy the configuration file across.  This was why the database
> > approach appealed at first as all I need to do is copy the database
> > and everything is in there.
> > 
> > I'm not really expecting quick/glib answers, just some ideas and
> > comments on the various ways of doing this and their advantages and
> > disadvantages.
> 
> Main next question is whether you can restart each system when you
>  add to the configuration.  
> 
Yes, restarting isn't a problem, the Beaglebone is dedicated to this
task and doesn't control anything so restarts are not an issue.  

-- 
Chris Green
·