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. > 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. > [snip...] > Mapping protocol is fine. Subclassing dict has the advantage that some > aspects of the API are already implemented in C. And many you don't need. You'll never be able to change the API because it's constrained by all existing uses, which means every dict API you've never heard of. If you're using this so much that speed's an issue perhaps you're overusing it. > 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. 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? -- --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
