For our Python scripts we have used a fair number of idioms and variations such as importing a config.py file with the parameters as module global vars or importing the content of a dictionary. A different one we used lately is very useful and simple:
# This should be your program using the config
import os
class config :
#Here we define the default parameters
paramA = "value A"
paramC = "value C"
class category1 :
paramC="value sub C"
#Here we load new values from files, if they exist
for configFile in [
"/usr/share/myprog/defaultconfig",
"/etc/myprog.conf",
"~/.myprog/config",
"myconfig.conf",
] :
if not os.access(configFile,os.R_OK) : continue
execfile(configFile)
# That's the config params usage. Pretty!
print config.paramA
print config.paramB
print config.paramC
print config.category1.paramC
print "This is a template: %(paramC)s" % config.category1.__dict__
If you write in the config file this:
# myconfig.conf
paramA="new value A"
paramB="new value B"
category1.paramC="new subCvalue"
paramB+=" extension " + paramA
you'll get this
new value A
new value B extension new value A
value C
new subCvalue
This is a template: new subCvalue
The config file is read as you were adding code at the same indentation level you have on the 'execfile' call.
Notice the advantages:
- Your config file looks like var assignations
- You can use inner classes to build up categories
- You can have a list of configuration locations with different precedence
- You can include almost whatever python code
- You can do templating with the params getting a dictionary like config.__dict__ or config.category1.__dict__
- You can put config checking code after loading.
Be carefull on unreliable contexts:
- Malicious config files can include almost whatever python code
- Config syntax errors crash the program (i guess that can be solved)
- Config files may add any new attribute, category, or method you didn't have
But if you are just managing your own utility scripts like us, that idiom is fantastic.
No comments:
Post a Comment