[Python-Dev] Extension to ConfigParser (original) (raw)

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