7 Python configuration files

Python based configuration files may be used in place of or in combination with ini configuration files. Since this may introduce a security hole in your application, this feature must be enabled using the allow_py argument when creating an instance of the ConfigParser.

Use of Python to construct option settings allows the greatest flexibility but also requires a bit more sophisticated user as the configuration file is truly a Python script and is executed. One significant advantage of a Python based configuration file is that settings may be Python objects. For example in an application where files need to be located it may be tempting to ask the user to provide a string which contains a list of paths to scan. What happens if the user wants a set of text files that contains lists of files (such as Visual Studio project files) scanned instead? It would be better to provide a base class that is your best guess as to what most users need. Most users could then make the settting an instance of that class passing in the string of paths into the constructor. Advanced users can would be able to subclass it, maintaining the interface, but changing the implementation to their particular needs.

Another significant advantage is that users can construct settings on the fly with the full power and flexibility of Python. There are no special text substitution techniques like the ini syntax since the user can use Python to do it.

KEYS = 'RACK0,DEV0'

[DEFAULT]
<keys> = RACK0,DEV0

KEYS_VARIABLE = 'keys'

[DEFAULT]
<keys_variable> = keys

CONFIG_FILES = 'file1.ini'

[DEFAULT]
<include> = file1.ini

CONFIG_FILES = ['file2.ini','file3.py']

[DEFAULT]
<include> = file2.ini
<include> = file3.ini

CONFIG_FILES = { 'DEFAULT' : 'rack0.ini',
                 'RACK1' : 'rack1.ini', 
                 'RACK2' : 'rack2.ini' }

[DEFAULT]
<include> = rack0.ini
[RACK1]
<include> = rack1.ini
[RACK2]
<include> = rack2.ini

After execution of the configuration file all remaining options found that do not begin with an underscore (_) are considered to be an option setting. To avoid polluting the settings dictionary the configuration files should either clean up after itself or name intermediate variables with an underscore. For example:

# import with leading underscore to avoid cleanup later
import os as _os

for x in range(10):
    pass # do something
del x # clean up so don't need leading _

driver = 'ethernet'
path = { 'DEFAULT' : '192.168.0.99',
         'DEV0'    : '192.168.0.0',
         'DEV1'    : '192.168.0.1' }

[DEFAULT]
driver = 'ethernet'
path = 192.168.0.99
[DEV0]
path = 192.168.0.0
[DEV1]
path = 192.168.0.1