ConfigParser shootout, K.I.S.S. entry.

[Ian Bicking]

David Wilson wrote:
> Greetings Python-List,
> 
>     http://botanicus.net/dw/tmp/ConfigParser2/ConfigParser.py
> 
> 
> The above implementation of 'ConfigParser2' takes a radically different
> approach to that of the good Mr. Chermside's entry, or any of the
> so-called proposed 'enhancements' to ConfigParser. It does this by
> *removing* features which I believe do not belong in ConfigParser, and
> repairing the existing class interface.
> 
> Please let me know what you think, CC: me if possible. This module,
> although unused (and only an hour or three old), will probably live in
> my personal toolkit from now on. Its interface is superior to that of
> ConfigParser's in many ways, despite being less than 51% of the size of
> it's predecessor:

It's simplicity really seems like a combination of two things: (a) a 
simple INI file parser, (b) a multi-value dictionary.  With sections 
mixed in there somewhere as well.  I find sections to be a somewhat 
confusing metaphor -- should sections be their own object, or are 
configuration keys just parameterized (i.e., each key is really a tuple 
of (section, name))?

But that's really not so bad; whether those concerns are separated out 
or not, I don't really mind either.  But one issue I see with this is 
that it doesnt allow for very good error messages.  Because all the 
parsing is done up-front, there's no information left about where 
exactly the errors are located.  When you have large configuration 
files, and cases where multiple configuration files are layered, or even 
layering sections within a config file, it becomes important to provide 
good error messages.

And then some minor nits: you don't check for the trailing ] on section 
names (or strip whitespace), # isn't allowed for comments, and : isn't 
allowed in place of =.  Also, line continuation isn't provided for.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org