Guido van Rossum wrote: > On 1/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > Michael So-and-so ??? Hey, that's fighting talk. ;-) > It's suboptimal if it says > > From: Fuzzyman <[EMAIL PROTECTED]> > > 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@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > > _______________________________________________ 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