[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