Guido van Rossum wrote: > On 1/30/06, Michael Foord <[EMAIL PROTECTED]> wrote: > >> I have a feeling that for many complex applications the developer is the >> user. Agreed that giving complex configuration data along with program >> data to the end-user is not good. >> >> Despite this, data storage that needs to be edited by developers and >> system administration is a very common usage. >> >> I'm saying that for this purpose (up to a point) an INI file like syntax >> is much *better* than XML. >> > > Sure. But for the same reasons, arbitrary nesting is probably bad. > > Interesting. It's one of the most frequent complaints (lack of nesting) I hear about ConfigParser. I guess I hang out in different circles.
I still think it's a convenient way of grouping related options. Breaking them out into separate files is another way. >> I'm not really sure there is such a clear distinction. Especially for >> programs without a GUI, things like IP addresses, network details, paths >> to data files, plugged in components, device names, (etc) seem to be both. >> > > Just try to keep it simple. > > I still think it's a typical programmer's mistake to assume that > there's no clear distinction. For a user who's looking to change one > of the three simple properties that make sense for him to configure, > having to hunt these down in a file containing hundreds of stuff she > shouldn't tuch is a pain, plus there's the risk that an occasional > slip of the finger causes damage to stuff they don't understand. > > Right, I guess I'm still thinking more of the developer than user. For end-user simpler is definitely better. I still see use cases for ConfigObj where complex editable data (relatively - not database record sets) needs to be stored, and COnfigObj syntax is preferable to XML. > [snip..] >> Anyway - I modify my statement accordingly. For accessing configuration >> type data, the mapping protocol is an intuitive match. Named members >> mapping to values. Whether this is done via subclassing dict is an >> implementation detail. (Although I guess it implies that the full >> dictionary API will be available and you seem to be saying that you >> would rather that *only* relevant methods are available). >> > > I can see several improvements on the dict protocol. For example, a > handy API would be soemthing that produces a default value that is > specific to the key you are requesting. Using dict.get(key, default) > has the problem that if you ever decide to change the default you'll > have to modify every place that references it. If would be nice if you > could use dict.get(key) or even dict[key] and it gave you a default > that was specified once when the the file was read. We do this through the schema. You specify a default value for keys (optionally). This is supplied if the value is missing, but isn't written out again unless modified. For a *simpler* case (no possibility of a write) you can just merge in two config files, user data over the defaults. It doesn't keep a track of which file values come from though (your use case below). > Another idea: have > a list of multiple dict objects representing different config files > (e.g. ./.appconfig, ../appconfig, ../../appconfig, ..., ~/.appconfig, > /etc/appconfig, /opt/app/config). The dict semantics get in the way > when making changes -- which file should be updated? > > Hmmm.... all in all, I guess this is no. ConfigObj is fine as a separate module, and it's features are well used - so to that extent the status quo is fine. Have we got anywhere on an updated spec for ConfigParser replacement/enhancement ? Suggested features seem to include : * Round tripping (preserving order and possibly comments) (http://python.org/sf/1410680 maybe) * Mapping protocol for access is not a bad idea * List values seem a no brainer good idea to me * Better support for default values * Keeping track of values from multiple files, and writing changed values to the correct file We haven't discussed unicode of course, seems like a good idea for a text format. (It was one of the motivations for an alternative implementation Dict4ini.) I'd also like to see values allowed without a section. Flat config files with a few values are appropriate for many applications. (Maybe section=None to access, this was the approach for ConfigObj 3). Maybe the shooutout needs an update. All the best, Michael Foord > -- > --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
