ConfigParser shootout, preliminary entry

Vinay Sajip vinay_sajip at yahoo.co.uk
Sun Oct 24 02:05:39 CEST 2004


I think we need to separate two concerns: a parser for the Microsoft
.ini file syntax (which David Wilson is arguing for, AFAICT) and the
need for a more powerful configuration file format and API which
supports more flexible configuration than .ini files can provide
(which I would argue for).

Since applications (and subsystems - e.g. logging) are often
constructed as hierarchies of components (often quite deep
hierarchies), it seems logical that application configuration should
support reasonably deep hierarchies, too. The .ini file format does
this, but it's very very basic, really only a two-level hierarchy
(unless jumping through hoops is desired) - that's why Windows uses a
registry. I have to say that my experience with ConfigParser and
logging configuration has made me want to find something better.

XML is a widely used substrate for defining unrestricted hierarchies,
but it suffers from excessive verbosity for some applications. I think
something more Pythonic would be better: since containers are
typically either dicts or sequences, a configuration would ideally
consist of a container hierarchy denoted by Python's literals syntax
for dicts and lists.

I would like to present for consideration an alternative hierarchical
file format, which is in the early stages of design (configuration
files can be read and written but the API for access is still
undecided). This format is not particularly original or innovative,
but it is certainly simple and to my eyes seems reasonably Pythonic in
style. There are more details on the Python Wiki: see

http://www.python.org/moin/HierConfig

Please feel free to post comments on the Wiki, which shows example
configuration files. I'd like to see if people think the approach has
sufficient merit to warrant even thinking about putting a PEP
together. The present design is, as I said earlier, in a preliminary
stage: so please be gentle.

Many thanks,


Vinay Sajip



More information about the Python-list mailing list