Many programs are built these days by assembling components together, and Python programs are no exception. In general, the designer may choose to expose multiple configuration points, and will benefit if there is one standard way of doing so. From the perspective which views programs as hierarchical constructions of configurable components, it would seem to follow logically that configuration of the components should also be hierarchical in nature. The two-level (section, key) model as exemplified by the present ConfigParser does not offer sufficient power. If it did, why does Windows need a registry?

I've been thinking about how to improve the configuration of the logging package (which currently uses ConfigParser) and playing with some ideas which may have more general applicability. I'm posting them here and seeking feedback.

I think a good configuration system should provide the following (in addition to being textual, easy to read and edit):

1. Allow a hierarchy of configuration information, with no specific limit on the depth of the hierarchy.
2. Allow inclusion of sub-configurations held in external files, at any point in the hierarchy
3. Allow the defining of sequences of items as well as items accessed by key
4. Allow late-bound references to any point in the hierarchy

5. Allow simple expression evaluation, but not unrestrained eval()-type functionality.

6. The ability to specify standard library entities (e.g. sys.stderr or os.sep)

To illustrate these points, two example configuration files are given below. Please forgive the bias towards logging-related configuration. (My excuse is that I'm thinking about how to make logging configuration easier.)

The first is the application configuration file. It includes the logging configuration file using the notation @"logging.cfg".

app:
{
  name : MyApplication
  base: '/path/to/app/logs/'
  support_team: myappsupport
  mail_domain: '@my-company.com'
}
logging: @"logging.cfg"

The second file contains the logging configuration. It refers to the application configuration through $app

root:
{
  level     : DEBUG
  handlers  : [$handlers.console, $handlers.file, $handlers.email]
}
handlers:
{
  console:  [ StreamHandler, { level : WARNING, stream  : `sys.stderr` } ]
  file:     [ FileHandler, { filename: $app.base + $app.name + '.log', mode : 'a' } ]
  socket:   [ `handlers.SocketHandler`, { host: localhost, port: `handlers.DEFAULT_TCP_LOGGING_PORT`} ]
  nt_eventlog: [`handlers.NTEventLogHandler`, { appname: $app.name, logtype : Application } ]
  email:    [ `handlers.SMTPHandler`,
              { level: CRITICAL,
                host: localhost,
                port: 25,
                from: $app.name + $app.mail_domain,
                to: [$app.support_team + $app.mail_domain, 'QA' + $app.mail_domain, 'product_manager' + $app.mail_domain],
                subject: 'Take cover' } ]
}
loggers:
{
  "input"     : { handlers: [$handlers.socket] }
  "input.xls" : { handlers: [$handlers.nt_eventlog] }
}

The $-notation resolves entries when they are required. The use of specific characters such as '@' and '$' is preliminary and can be easily changed. You can lay out the file with as much whitespace as you like - indent according to taste.

I'm currently working on a module to parse this format, though I've nothing which is yet in a fit state to show

-- VinaySajip

[http://cvs.zope.org/Zope3/doc/zcml/ ZCML] (unlike .ini files) handles nested input fairly well. The syntax looks a little like an Apache config; though from much of what I've seen, it's straight XML. -- IanBicking

• Is there a better link for ZCML than the one above? There appears to be nothing in the form of overview documentation on the Zope site, including dev.zope.org - I did site searches for "ZCML" and "configuration" and nothing came up which looked immediately useful. I don't have a particular problem with ZCML, other than the fact that by dint of being XML, it is fairly verbose; and I would guess (please correct me if I'm wrong) that it is Zope-centric rather than general-purpose. -- VinaySajip

Maybe I'm confusing ZCML and [http://www.zope.org/Members/fdrake/zconfig/ ZConfig]; there's a ZConfig presentation at http://zope.org/Members/mcdonc/Presentations/ZConfigPaper -- ZCML is much more XML-based, where ZConfig is like an Apache file. ZCML is used for a lot of configuration inside Zope 3, which has a very different idea of what configuration is. (Intended for "system integrators" as opposed to "system administrators".) I believe both were intended to be usable outside of Zope, but haven't been packaged as such (yet).

Another way to deal with nested configurations would be to parse the names. I think one package I've seen does this. So sections are just a sort of "with" statement. I.e.:

loggers.input = nt_eventlog
[logggers]
input.nt_eventlog.filename = /some/path

Well, not a very good example. Anyway, this creates the keys "loggers.input" and "loggers.input.nt_eventlog". This works for keys that are nicely named; it might be harder for a virtual host, which I'd be apt to do like:

[vhost my.vhost.domain]
document_root = /some/path

Or something like that. Anyway, you want to create something like vhost['my.vhost.domain'].document_root, not vhost.my.vhost.domain.document_root. Maybe it could be like:

vhost[my.vhost.domain].document_root = /some/path
# or....
[vhost[my.vhost.domain]]
document_root = /some/path

Anyway, there's still some other possibilities when using the ini syntax.