[Python-Dev] Extension to ConfigParser

Vinay Sajip vinay_sajip at yahoo.co.uk
Tue Jan 31 17:13:19 CET 2006


Fuzzyman <fuzzyman <at> voidspace.org.uk> writes:

> In my opinion dictionary syntax is the most natural way to represent a
> config file - it is a data structure with named members. This means the
> API for accessing the data - whether from a subclass that does
> additional value processing or from code that just accesses the data.

I agree with this, and also with Michael's comments that configuration is not
just for the end user. (Alternatively, you could say that developers are end
users too!)

As a developer who works for many different clients, I find it saves me a fair
amount of time when I have configurable software modules which I can put
together to meet client requirements. The client doesn't need to see this
"internal" configuration stuff - it's for developers and maintainers of the
software, but very useful nonetheless!

When I implemented my own config module (see
http://www.red-dove.com/python_config.html), I decided not to use an INI-like
format, as I found it wanting. The syntax I used is like Python and like JSON,
but it is not executable (i.e. not Python) and allows bits of the configuration
to refer to other bits of the configuration, provides some restricted evaluation
of values such as "sys.stderr" but in a general way, readily allows defaults at
different levels (e.g. user, program, suite), handles repeating values and
mappings, uses dict or attribute syntax etc. - and all in a single 1500-line
module, since I didn't have to implement INI support.

What I'd like to know is, what happens how? There are a whole lot of
alternatives put forward in the ConfigParserShootout wiki page, but how do we
move things forward from here?

Regards,


Vinay Sajip



More information about the Python-Dev mailing list