[Python-ideas] A Pythonic replacement for ConfigParser?

Fred L. Drake, Jr. fdrake at acm.org
Sun Feb 25 17:52:05 CET 2007


On Friday 23 February 2007 20:28, Larry Hastings wrote:
 > Ah, yes, ConfigParser, the red-headed stepchild of Python
 > serialization.  It seems ConfigParser has been around for a /very/ long
 > time... and it shows.  In particular, its interface is pretty clunky
 > when viewed with a modern Python programmer's eye.

There are a couple of aspects that need to be considered when selecting a 
replacement for ConfigParser.  The API is something everyone seems to 
understand needs improvements.  There are different ways to approach it in 
detail, and I don't think it's terribly important (though it would be nice).

The other is whether existing ConfigParser files needs to be supported.  If 
arbitrary files compatible with ConfigParser must work with the replacement, 
there are a lot of syntactical weirdnesses that need to be supported, and I 
don't know that re-implementing that is valuable at all.

Something that strictly supports ".ini" file syntax has the problem that it 
doesn't support arbitrary ConfigParser files, and that there's no appearant 
real specification for the format.

There are many libraries designed to provide support for general configuration 
files without supporting either the old ConfigParser files, these can provide  
a more "modern" API, but share the issue of compatibility with existing data 
files.

Given that data is harder to change than code, I'm not inclined to replace 
ConfigParser at all.  A new library (newly written or newly selected) could 
be added to avoid the ConfigParser issues for configuration files for new 
applications, but there's not really much value in a ConfigParser 
replacement.


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>



More information about the Python-ideas mailing list