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>