[Python-Dev] ConfigParser shootout, preliminary entry

Bengt Richter bokr at oz.net
Tue Oct 19 00:43:16 CEST 2004

On Mon, 18 Oct 2004 17:51:58 -0200, Carlos Ribeiro <carribeiro at gmail.com> wrote:

>On Mon, 18 Oct 2004 12:20:46 -0700, Josiah Carlson <jcarlson at uci.edu> wrote:
>> > > I think the syntax looks good, but as per a thread in python-list, you
>> > > cannot discover the order of class variables by any solution (metaclass
>> > > or otherwise), due to the fact that they become part of the class
>> > > dictionary; which is arbitrarily unordered.
>> > >
>> > > If ordering is important to a user, one could have an optional
>> > > __order__
>> > > attribute that gives the list of items in-order.
>> >
>> > That's not quite true.  TypedAttribute instances and iniSection's
>> > __new__ could have serial numbers.
>TypedAttributes store their own sequence numbers using a simple
>counter. Bengt Richter also came up with a clever trick to retrieve a
>list from the code object itself (using the inspect module and the
>co_names member). It's very powerful, but it can't check all
>situations, but I'm sure that it would work for most real world
>As far as INI files are concerned, order is good but not essential. It
>helps people that are going to read, or manually edit the config file,
>and avoids some surprised such as in "what has happened here?" when
>things seems to appear "out of order".
Has anyone discussed using the csv module as the basic file interface for config data?

Windows sort of migrated away from actual .INI files to using the registry, and a
registry entry with the name of a real ini file can divert apparent operations on
the file to operations on the registry (for windows apps using the windows API).

Order does matter in M$ view of INI files. IOW you _can_ (advisability of using ini
sections that way in another thing ;-) retrieve multiple sym value info from a section
such as


Basic usage is simple and ok, but a clean general info repository it is not, IMO.
The win32 API for reading and writing INI files is the family of "profile string"
operations, i.e., this gives an idea of what you are dealing with:

    The GetPrivateProfileSection function retrieves all of the
    keys and values for the specified section from an
    initialization file. This function is provided for
    compatibility with 16-bit applications written for Windows.
    Win32-based applications should store initialization
    information in the registry.
Windows 95: The specified profile section must not exceed 32K.

Windows NT: The specified profile section has no size limit.

DWORD GetPrivateProfileSection(
  LPCTSTR lpAppName,        // address of section name
  LPTSTR lpReturnedString,  // address of return buffer
  DWORD nSize,              // size of return buffer
  LPCTSTR lpFileName        // address of initialization filename
    Pointer to a null-terminated string containing the section
    name in the initialization file.
    Pointer to a buffer that receives the key name and value
    pairs associated with the named section. The buffer is
    filled with one or more null-terminated strings; the last
    string is followed by a second null character.
    Specifies the size, in characters, of the buffer pointed to
    by the lpReturnedString parameter.
Windows 95: The maximum buffer size is 32,767 characters. 

    Pointer to a null-terminated string that names the
    initialization file. If this parameter does not contain a
    full path to the file, the system searches for the file in
    the Windows directory.
Return Values
    The return value specifies the number of characters copied
    to the buffer, not including the terminating null character.
    If the buffer is not large enough to contain all the key
    name and value pairs associated with the named section, the
    return value is equal to nSize minus two.

    The data in the buffer pointed to by the lpReturnedString
    parameter consists of one or more null-terminated strings,
    followed by a final null character. Each string has the
    following format:


    The GetPrivateProfileSection function is not case-sensitive;
    the string pointed to by the lpAppName parameter can be a
    combination of uppercase and lowercase letters.

    This operation is atomic; no updates to the specified
    initialization file are allowed while the key name and value
    pairs for the section are being copied to the buffer pointed
    to by the lpReturnedString parameter.

    Windows NT: Calls to private profile functions may be mapped
    to the registry instead of to the specified initialization
    files. This mapping occurs when the initialization file and
    section are specified in the registry under the following

Windows NT\CurrentVersion\IniFileMapping

    This mapping is likely if an application modifies
    system-component initialization files, such as CONTROL.INI,
    SYSTEM.INI, and WINFILE.INI. In these cases, the
    GetPrivateProfileSection function retrieves information from
    the registry, not from the initialization file; the change
    in the storage location has no effect on the function's

    The Win32 profile functions (Get/WriteProfile*,
    Get/WritePrivateProfile*) use the following steps to locate
    initialization information:

    Look in the registry for the name of the initialization
    file, say MYFILE.INI, under IniFileMapping:
    HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows

    Look for the section name specified by lpAppName. This will
    be a named value under myfile.ini, or a subkey of
    myfile.ini, or will not exist. If the section name specified
    by lpAppName is a named value under myfile.ini, then that
    value specifies where in the registry you will find the keys
    for the section.
    If the section name specified by lpAppName is a subkey of
    myfile.ini, then named values under that subkey specify
    where in the registry you will find the keys for the
    section. If the key you are looking for does not exist as a
    named value, then there will be an unnamed value (shown as
    <No Name>) that specifies the default location in the
    registry where you will find the key.

    If the section name specified by lpAppName does not exist as
    a named value or as a subkey under myfile.ini, then there
    will be an unnamed value (shown as <No Name>) under
    myfile.ini that specifies the default location in the
    registry where you will find the keys for the section.

    If there is no subkey for MYFILE.INI, or if there is no
    entry for the section name, then look for the actual
    MYFILE.INI on the disk and read its contents.

    When looking at values in the registry that specify other
    registry locations, there are several prefixes that change
    the behavior of the .INI file mapping:

! - this character forces all writes to go both to the registry and to the .INI file on disk. 
# - this character causes the registry value to be set to the value in the Windows 3.1 .INI file
    when a new user logs in for the first time after setup. 
@ - this character prevents any reads from going to the .INI file on disk if the requested data
    is not found in the registry. 
USR: - this prefix stands for HKEY_CURRENT_USER, and the text after the prefix
       is relative to that key. 
SYS: - this prefix stands for HKEY_LOCAL_MACHINE\SOFTWARE, and the text after the prefix
       is relative to that key. 
See Also
Registry Overview, Registry Functions, GetProfileSection, WritePrivateProfileSection 

>> I'm not saying that they can't be numbered, I'm saying that one cannot
>> discover the ordering of assignment of attr1 and attr2 in the following:
>> class foo:
>>     attr1 = value1
>>     attr2 = value2
>> If there is a mechanism for discovering the original ordering of those
>> assignments, there are a group of users in c.l.py who would like to know,
>> and Carlos' seemingly non-existant implementation could also use it.
>I took part in that discussion. We found some a few alternatives to
>handle this problem. None of them are 100% percent transparent _and_
>reliable; you had to choose here between the two options. But for
>things such as ini files, things don't look that bad.
>As for the code: I don't have a host for it, and I just felt that I
>shouldn't post it in the python-dev list without some proper care :-)
>But I'm going to do it as soon as I have a 'good enough'
>implementation that include the write code. BTW I'll move this
>discussion to the main python list. If anyone cares enough about it,
>I'll move it back into python-dev.

Bengt Richter

More information about the Python-list mailing list