The basic idea being to get the Python interpreter to deal with the processing of the configuration file. This gives you access to the full set of syntax allowed by the Python language. For example, one thing I find I am frequently doing is writing code in my development environment, which I’d like to be able to directly deploy out to test and production environments. However, keeping track of multiple configuration files can be a pain. It would be nice to be able have the configuration tailor itself depending on the machine it’s running on:

[File “execfile-example-1.conf”]
import os
if os.uname()[1] == ‘development.example.com’:
server = ‘mail-test.example.com’
else:
server = ‘mail.example.com’

Using the execfile() Python built-in makes it easy to process such a configuration file. Set up a name-space (dictionary) with default value for server, and have Python parse the configuration file:

config = { ‘server’ : None }
execfile(‘execfile-example-1.conf’, {}, config)

The value of the server variable now depends on which machine it is run on. For example, on the development.example.com machine:

>>> print config[’server’]
mail-test.example.com

The execfile() built-in executes the Python code in the file specified in the first argument (execfile-example.conf). The next two arguments specify the global and local name-spaces, respectively. So, in this example we created a default configuration in which server was set to None. The code in the configuration file then checked what the system name was (with os.uname()[1]) and re-set the server variable in the local name-space.

You can get a bit more fancy than just “name”=”value” mappings, with little additional code. Returning to our mail-retrieving example, you may want to set some global values, and allow the user to poll various mail servers. This can be done by using a class that controls the configuration data:

class config:
def __init__(self):
self.config = {
‘interactive’ : 0,
‘verbose’ : 0,
‘poll’ : self.poll,
            }

def poll(self, server, **kwargs):
  if self.config[’interactive’]:
  if raw_input(‘Fetch mail from server “%s”? ‘ % server) != ‘y’:
if self.config[’verbose’]:
print ‘Aborting poll at user request.’
return

if self.config[’verbose’]:
print ‘Retrieving mail from server “%s”’ % server
print ‘  args: %s’ % str(kwargs)

#  poll mail server here
def runconfig(self, filename):
execfile(filename, {}, self.config)

While the above looks more complicated than our original example, at its heart it’s the same execfile call. Most of the code is the application logic which responds to the poll() action. The class sets up two configuration values (interactive and verbose) and a function. Note that for this example we’re using the **kwargs syntax. This tells the Python interpreter to hand us the function’s keyword arguments as a dictionary. It could just as simply have been a list of the arguments expected:

if os.uname()[1] == ‘development.example.com’:
verbose = 1
interactive = 1
poll(‘mail.example.com’, 
      username=‘jsmith’, 
      password=‘My^Hat’, 
      protocol=‘pop2’, 
      localuser=‘John.Smith’)

This one sets verbose and interactive flags if the program is running on the development machine. It can be run by passing the name of the configuration file to the runconfig() method of the config object:

config().runconfig(‘execfile-example-2.conf’)

This produces the following output on the development machine:

Retrieve mail from server “mail.example.com”? [y]
Retrieving mail from server “mail.example.com”
args: {’protocol’: ‘pop2’, 
      ‘password’: ‘My^Hat’, 
      ‘localuser’: ‘John.Smith’, 
      ‘username’: ‘jsmith’}

As shown, this configuration mechanism allows for the execution of arbitrary code in the configuration file. Care must be taken in the event that the configuration file is writable by a user with privileges other than the user running the system. For example, a program running periodically from cron with root privileges should not read a configuration file that’s writable by a non-privileged user. This is not a concern exclusively with this configuration mechanism. You rarely want a root-level process directed by a user-writable configuration file. However, the power and flexibility of this mechanism makes it particularly easy to exploit. There are things that can be done if writing an application that runs with one user’s privileges, but need to read configuration files written by another user. For example, before reading the configuration file, the program can assume a lower-privileged user’s identity. With appropriate consideration of the security issues, this configuration mechanism can safely become a useful part of your programming toolbox.

I have used this mechanism successfully in a number of projects. It’s amazing how quickly you can make rather complex configuration systems. In a number of cases I’ve found that what would normally be special cases in the code could be moved off to the configuration file, and allow the ultimate flexibility.

One particular benefit is that users who are unfamiliar with Python can stick with fairly simple “name”=”value” and function(args) calls (which most people understand), while users who are familiar with Python can very easily tailor the operation of the system to their liking.