> Guido van Rossum wrote: > > 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.)
On 1/30/06, Michael Foord <[EMAIL PROTECTED]> wrote: > 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. Ah. This definitely isn't what ConfigParser was meant to do. I'd think for this you should use some kind of XML pickle though. That's horrible if end users must edit it, but great for saving near-arbitrary persistent data in a readable and occasionally editable (for the developer) form. You should probably not mix the end user config data with the program's persistent store. > 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. And I'm trying to say that (for config files) they probably shouldn't, because most of their users won't understand it. Of course this doesn't apply to your use case, so maybe we're just violently agreeing -- except you seem to be confusing matters by talking about "configuration" (which suggests end-user-editable) when you really mean "persistent state" (which is under full program control). > > 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. ;-) Yeah, but that was more as a matter of principle than to encourage that use... Narrow APIs are typically better than wide APIs, and the dict API is the ultimate wide API. (I guess strings are just as bad; I haven't contributed to that thread yet but I think the new path module should not inherit from str or unicode either.) > 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. has_key is obsolete though -- use 'in'. Anyway, we have a name for this -- we call it the "mapping protocol". In most cases it's better to implement a protocol than inherit a standard object. (This is perhaps unique to Python -- other OO languages often encourage inheritance, so I can understand the confusion.) > 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.) Thanks much! -- --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/archive%40mail-archive.com
