[Python-Dev] Extension to ConfigParser

[Guido van Rossum]

On 1/30/06, Michael Foord <fuzzyman at voidspace.org.uk> 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/)