[Python-Dev] Extension to ConfigParser (original) (raw)

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

Fuzzyman <fuzzyman 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