[Python-Dev] Extension to ConfigParser

[Michael Foord]

Guido van Rossum wrote:
>
> On 1/30/06, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
>   
>> But like it or not, configuration files are often used to store data
>> about what a program does - not just the UI options. Storing this in a
>> human readable and editable format is of great advantage.
>>
>> Yes, a lot of the entries will never be modified by a user - but many
>> will need to be edited and read by a developer. In a production
>> environment importing from python modules is not likely to be safe.
>>     
>
> Ah. This definitely isn't what ConfigParser was meant to do. I'd think
> for this you should use some kind of XML pickle though. That's
> horrible if end users must edit it, but great for saving
> near-arbitrary persistent data in a readable and occasionally editable
> (for the developer) form.
>
> You should probably not mix the end user config data with the
> program's persistent store.
>
>   
I have a feeling that for many complex applications the developer is the
user. Agreed that giving complex configuration data along with program
data to the end-user is not good.

Despite this, data storage that needs to be edited by developers and
system administration is a very common usage.

I'm saying that for this purpose (up to a point) an INI file like syntax
is much *better* than XML.

>> I don't dislike the INI format. ``key = value`` is intuitive. Nesting of
>> sections is a logical extension that provides additional flexibility
>> without breaking backwards compatibility. It needn't be added
>> complexity, because you don't need to use it. There are plenty of people
>> who will though.
>>     
>
> And I'm trying to say that (for config files) they probably shouldn't,
> because most of their users won't understand it. Of course this
> doesn't apply to your use case, so maybe we're just violently agreeing
> -- except you seem to be confusing matters by talking about
> "configuration" (which suggests end-user-editable) when you really
> mean "persistent state" (which is under full program control).
>
>   
I'm not really sure there is such a clear distinction. Especially for
programs without a GUI, things like IP addresses, network details, paths
to data files, plugged in components, device names, (etc) seem to be both.

>>> Regarding the claim that dicts are the best kind of API for
>>> configuration, I disagree 
[snip..]
>>  Hey, since Python 2.2 some folk put a lot of
>> work in allowing us to subclass dict. ;-)
>>     
>
> Yeah, but that was more as a matter of principle than to encourage that use...
>
> Narrow APIs are typically better than wide APIs, and the dict API is
> the ultimate wide API. (I guess strings are just as bad; I haven't
> contributed to that thread yet but I think the new path module should
> not inherit from str or unicode either.)
>
>   
I am a firm fan of the new path module but agnostic on whether it should
inherit from basestring in some way. Wrong thread though.

[snip...]
>
> Anyway, we have a name for this -- we call it the "mapping protocol".
> In most cases it's better to implement a protocol than inherit a
> standard object. (This is perhaps unique to Python -- other OO
> languages often encourage inheritance, so I can understand the
> confusion.)
>
>   
Mapping protocol is fine. Subclassing dict has the advantage that some
aspects of the API are already implemented in C.

Anyway - I modify my statement accordingly. For accessing configuration
type data, the mapping protocol is an intuitive match. Named members
mapping to values. Whether this is done via subclassing dict is an
implementation detail. (Although I guess it implies that the full
dictionary API will be available and you seem to be saying that you
would rather that *only* relevant methods are available).

All the best,

Uhm... Michael Foord I guess