Python's ConfigParser module is part of the standard library. The module provides a parser for simple configuration files consisting of groups of named values. The best known format supported by this module is the "INI" syntax, most commonly used on the Microsoft platforms. The module was originally written to support a variant syntax in which the contents of each section resembled RFC 822 headers; the implementation still allows named values to be specified using either syntax. Between this historical accident and lack of a clear specification of the "INI" format has made this module very tedious to maintain, so the implementation has been changed in almost every Python release, and the behavior of the module has proven very tedious to describe completely.

The current behavior of the defaults has always been what was intended. The module was designed to support a suite of programs that could provide some information that was either used directly or to form parts of other values (such as path names that included the host name of the computer running a program). There was at the time no need to distinguish between different uses of "default" values, as MartinManey suggests below. (It's not clear to me know that there's a real need to do so, since the API provided by ConfigParser is so spare.)

I've been thinking about writing up some thoughts I've had while trying to use ConfigParser for what seemed like a dirt-simple application a while ago. I ran into both the handwaviness of the documentation and either the every version some changes effect or perhaps it was just a bug shared by 2.1 and 2.2 (IIRC). Here I feel less inhibited from posting a rough draft, so...

The problem I ran into was the handling of the default section. Apparently the latest thinking is that items in the default section should appear as items in every section. The version(s) I was using only injected them into the dictionary used for parameter substitutions (I think that was how it went, anyway). In the course of getting this straightened out, I had the thought that there are really two different types of defaults that would be useful, or perhaps three. One sort would supply default definitions only for substitution; its entries would never be pushed into the sections' namespaces. The other sort works as I understand the 2.3 library version does, which may have been intended all along, and injects the default entries into every section (and hence are available for substitutions). I'd like to have the first sort available, too. This seems to require another magic section name.

There, that's the essence of my too-small-for-a-PEP talk! MartinManey