There has been some recent debate about [http://python.org/doc/current/lib/module-ConfigParser.html ConfigParser] on the Python mailing lists. For more, see these threads:

• [http://mail.python.org/pipermail/python-dev/2004-October/049167.html ConfigParser patches]

• [http://groups.google.com/groups?hl=en&lr=&c2coff=1&selm=mailman.5093.1098051158.5135.python-list%40python.org ConfigParser shootout, preliminary entry; comp.lang.python]

• [http://mail.python.org/pipermail/python-dev/2004-October/049454.html ConfigParser shootout, preliminary entry; python-dev]

• [http://mail.python.org/pipermail/python-dev/2004-October/049527.html What are the goals for ConfigParser 3000?]

This page serves as a place to record alternatives, and discuss (in a semi-permanent way) the features such a library might have. A new configuration parsing library could go into the Python standard library, probably in addition to the current ConfigParser module (perhaps with that module being deprecated).

Broken Out Sections

• ConfigParserGoals: what is ConfigParser really for?

Implementations

Please list interesting implementations of config parsers here.

M. Chermside's candidate

[http://www.mcherm.com/publish/2004-10-17/config.py code] and [http://www.mcherm.com/publish/2004-10-17/configTest.py test cases]. Currently allows files in either str or unicode, with sensible defaults. Allows dictionary or dotted-name access (though dotted-name can fail in some cases). Allows subsections of arbitrary length. For example,

    x.y = True 
    x.y.z = 47
    x.y.a = prime

Would allow x.y to be viewed as either a value ("True") or a section.

    x.y == "True"

but also

    x.y['a'] = 'prime'
    x.y['z'] = '47'

Note that keys and values are always strings or unicode -- no autoconversion to other types. Note that this focuses on storage and API -- reading and writing is left out at the moment, and might reasonably be in a separate module for each format supported.

Features

This is a list of features that should be taken into account. Certainly not all these features are required; maybe some aren't even desired.

• Uses a human-editable source file format. Everyone seems fairly happy with INI files as a basis, but

  [http://cvs.zope.org/Zope3/doc/zcml/ ZCML] is an example of a different syntax.

• Has a simple API, especially for the simplest case (read a bunch of key-value string pairs from a file).
• Can be round-tripped, i.e. a program can modify the configuration, then write the new configuration out.
  • Bonus if you can keep comments intact when writing the file. Or at least keep track of the comments in some way, so it can be extended by someone else later (throwing away comments entirely puts up brick walls).
  • Keeps track of the order of items in the configuration file.
  • Is intelligent about default values; writes out a minimal config file.
• Supports some notion of a config schema. You might define a certain key as being an integer, and it would be automatically converted when the file was loaded. This becomes a bit more difficult when you have more complex structures, multiple sections, etc. Defaults fit in here as well. Obviously the types available should not be fixed.
• Supports repeating values in some fashion. Maybe a key can appear multiple times in the file. Maybe nested structures are allowed otherwise. Repeating values are common.
• Allows multiple config files to be combined, e.g., a site config, user config, custom config. Consideration should be given to repeating values; sometimes a user config file may want to add to a site config without repeating all items in the site config.
• Allows dynamic nesting. E.g., some configuration values may be modified only in a small context, or for a single request in a long-running server. The nesting needs to be undone later. Maybe this simply requires the config to be easily copiable (i.e., copy the config, modify that copy, throw it away when you are done); maybe something more sophisticated is possible.
• Supports multiple syntaxes; e.g., an XML plist syntax, an INI syntax, a ZCML syntax.
• Gives good error messages. Error messages should include file and line number. If we define types in a schema, invalid values should give good errors.
• Supports (maybe through utility functions or otherwise) more advanced configuration directives, like including other files or string

  interpolation. But a lot of people don't like ConfigParser's current string interpolation.

• Consider the general case of configuration settings, not just config.ini. While round-trip to human readable is important, it is also important that the in-memory version play well with other ways of setting parameters -- including some that set arbitrary python objects.

Discussion

Discuss. Please sign your name.

What exactly is the goal? A new API to access configuration info? Or a specific file format itself? Or both? I don't have much problem with the current ConfigParser but ideally I would like use a 'simpler' API. This would allow attribute access (a.b.c) to values, provide default values, convert some types, and do some constraint checking (xyz is required) etc. It's very possible to get this functionality through a wrapper on top of ConfigParser. IMO that is the best approach, as long as there is a way to map the same API over a different underlying file format, such as XML. I think the 'dynamic nesting' point above is outside the scope of the config access API. -- Shalabh

Complexity killed the cat!

Look at what happened to urllib2 - the entry level for new users was greatly enhanced, but the added functionality was really little more than what you could already do more simply with urllib. With that in mind, I think the new ConfigParser should in it's simplest form act very closely like the original ConfigParser.

• -- DavidWilson