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 [
    ] :
        if not os.access(configFile,os.R_OK) : continue

# 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.



Leave a comment