There has been some confusion between "In memory storage of configuration data" and "Simple persistent storage of configuration data". Part of the problem is that almost every configuration storage system (including ConfigParser, optparse, and getopt) comes with its own in-memory API. In memory needs a good programmer API. Persistent needs a good user API, and may not need to reflect the full power of the in-memory. How should we separate these?

I (VinaySajip) think these concerns are to some extent orthogonal. Access to values should be powerful but easy, whether the data comes from a persistent store or not. I presume that's what you mean by 'programmer API'. If by 'Persistent needs a good user API' you mean 'The file format should be easy to use', I agree. Or is there some other aspect of 'user API', other than the file format, which I'm missing?

Yes. They are orthogonal. But an API that is good for programmers (needed in-memory) is different from one that is good for users (needed for the persistent storage). Part of the problem is that most configuration solutions have tried to do both at once -- anything that could be represented by the program had to be represented by the text file (and often in exactly the same way), so either the text format got unwieldy, or the configuration options were too limited. -- JimJJewett

ConfigParser NG Goals: Competing Concepts

Keep It Simple And Useful

In this target, the existing ConfigParser interface is cleaned up and modernized. Features such as string interpolation should be separated out from the base ConfigParser class, in order to lower the entry level for usage and the overall simplicity of the base class.

Attribute and mapping-like access should not be included, as it teaches the Python beginner a bad habit early on in their programming life. Both are essentially syntactic hacks, attribute access also places unnecessary restrictions on the key item - it must be matched by [a-zA-Z_][a-zA-Z0-9_]+ (ie. Python identifier).


There is no single standard library module that I swear at more often than ConfigParser. It is beyond disgusting, yet it's core functionality is infinitely useful in nearly every small application I write. In none of these applications would a more complex configuration system be used, so adding a "ConfigParser2" in the style of urllib2 (needless complexity) would not benefit me at all. I suspect this is the case for most current users of the ConfigParser module. -- DavidWilson.




A variety of alternate configuration parsers are linked from the ConfigParserShootout page.

Rich, Complex Data Storage

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 posted a more detailed proposal on the HierConfig page.



ConfigParserGoals (last edited 2008-11-15 14:00:39 by localhost)

Unable to edit the page? See the FrontPage for instructions.