[Python-Dev] Extension to ConfigParser

Guido van Rossum guido at python.org
Mon Jan 30 22:56:37 CET 2006


On 1/30/06, skip at pobox.com <skip at pobox.com> wrote:
>
>     Guido> What's so bad about ConfigParser?
>
> My guess is that people find its limited nesting, well, limiting.  Python
> containers being the arbitrary nesting little devils that they are, I can
> understand the desire to push the envelope.

To the contrary. Config file syntax should be limited by design so as
to avoid confusing the people who have to edit them without knowing
Python, and if an app is successful, that's most of the app's users.
(If the app is only targeted at Python users, why bother with a config
file? You could just have one designated .py file where all the
configuration code is concentrated, like faqwizard's faqconf.py.)

> It's my opinion that ConfigParser should stay pretty much as it is other
> than perhaps adding round trip capability.  It is pretty good at reading and
> writing Windows INI files, which was what it was designed to do.  My guess
> is there are a fair number of people who wouldn't want to lose that.  Mixing
> INI file handling with something more powerful seems doomed.  If we want
> more sophisticated functionality a new module should be written, or one of
> the existing shootout candidates on the Wiki should be chosen and perhaps
> enhanced.  I have a horse in that race (actually, it's more like a pony).

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.)

Regarding the claim that dicts are the best kind of API for
configuration, I disagree -- the dict API doesn't maintain order, and
doesn't provide access to comments and other metadata. And it has many
operations that make little sense for configuration option values.

(And would Michael please start signing with his full name, since he
doesn't seem to care much for true anonymity? It's okay if your email
says

  From: Michael So-and-so <fuzzyman at wherever.com>

It's suboptimal if it says

  From: Fuzzyman <fuzzyman at wherever.com>

You might also start signing your posts "Michael So-and-so" rather
than the alias. I don't sign my email "BDFL" either. :-)  Since there
are many Michaels, signing just "Michael" doesn't really help. I'm too
old fogey to get used to using IRC handles to refer to people; I can
never keep the mapping in my head.)

--
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list