[Python-Dev] Extension to ConfigParser

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