On 1/30/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Aha. I am beginning to understand. When people say "ConfigParser is
> hopeless" they mean ".INI files are hopeless". I happen to disagree.
> (There's also a meme that says that every aspect of an app should be
> configurable. I disagree with that too. As Joel Spolski points out in
> his book on UI design, most configuration options are signs of
> indecisive developers, and most users never change the defaults.)
While you're right that a lot of the comments people make about
ConfigParser are actually about INI files (e.g., no nested sections,
no "top-level" values), I do find that when I use ConfigParser, I
often need to write a wrapper around it to make it more usable.
A couple of examples, from a current application:
* No way to merge files or sections. Usually to provide default
values. I have a suite of applications, all using the same framework.
I have a hardcoded DEFAULT_CONFIG in the code, overriden by a
<suite>.ini, overridden again by a <app>.ini. OK, maybe it's
overengineered, but I do use the various levels, so it's also
useful... (The defaults parameter to the constructor is misnamed,
AFAICT, as it's for interpolation defaults, not value defaults).
* A dictionary interface, or even attribute access (where the key
names are Python identifiers, which is usually the case), is usually
far cleaner to work with in code. For example, conf.log.level vs
conf.get('log', 'level'). But that may just be me - it's certainly a
style issue.
Nothing major, but worth considering.
I agree entirely that once you go beyond INI format, you should have a
new module. Of course, ConfigParser already allows more than basic INI
format ("key: value" lines, continuations, and substitution strings)
but we'll gloss over that... :-)
Paul.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
