|
⇤ ← Revision 1 as of 2003-09-05 00:55:40
Size: 783
Comment:
|
Size: 2152
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 12: | Line 12: |
---- 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 docs 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 though that there are really two different sorts 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 |
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.
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 docs 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 though that there are really two different sorts 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