[Python-Dev] ConfigParser shootout, preliminary entry
Bengt Richter
bokr at oz.net
Mon Oct 18 18:43:16 EDT 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
>situations.
>
>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
[section]
sym=value1
sym=value2
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:
_______________________________________________________________________________________________
GetPrivateProfileSection
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
);
Parameters
lpAppName
Pointer to a null-terminated string containing the section
name in the initialization file.
lpReturnedString
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.
nSize
Specifies the size, in characters, of the buffer pointed to
by the lpReturnedString parameter.
Windows 95: The maximum buffer size is 32,767 characters.
lpFileName
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.
Remarks
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:
key=string
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
keys:
HKEY_LOCAL_MACHINE\Software\Microsoft\
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
behavior.
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
NT\CurrentVersion\IniFileMapping\myfile.ini
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.
>
Regards,
Bengt Richter
More information about the Python-list
mailing list