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

Michael Foord fuzzyman at voidspace.org.uk
Mon Jan 30 23:17:10 CET 2006

Guido van Rossum wrote:

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

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.

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.

An ordered dictionary is a fairly trivial modification of the dictionary (if you don't mind the performance hit), and yes there is other metadata also needs to be stored. Hey, since Python 2.2 some folk put a lot of work in allowing us to subclass dict. ;-)

Perhaps a better way of saying this is that the dictionary API is an intuitive way to access config file data (including modifying and creating). You are mapping values to names, it's a logical match.

As soon as you generate/manipulate config files programattically a lot of the dictionary methods become useful. Perhaps not all though. get, update, has_key are all useful.

(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> Michael So-and-so ??? Hey, that's fighting talk. ;-)

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.) Wow, my first rebuke from the BDFL. May it be the first of many. ;-)

I've changed this client, but I use this account from multiple locations. Forgive me if I forget to change others (but feel free to remind me).

Michael Foord (Chastened but Fuzzy nonetheless.)

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

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk

More information about the Python-Dev mailing list