A configuration idiom for Python scripts
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__
orconfig.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.