On Sun, Oct 17, 2004 at 03:38:11PM -0700, Michael Chermside wrote:

My apologies, my previous email was intended to go to python-list, not python-dev. I didn't intend to bother this list with it until it was at a point where I thought it was a contender for inclusion. Sometimes I really wish there was an "Unsend" option for email.

I think it raised a point though - there were a few wildly different ideas about what ConfigParser's replacement should be. Would it be wise to discuss first what ConfigParser is *supposed* to be, and where it fits in peoples' applications? If this hits a chord with you, pump your reply button and discuss! If you look at the current ConfigParser, you might find the following: - It is a simple storage method for text data that categorises sets of keys with sets of values. - Its backend format is simple and fast for other tools to parse (even for on-request applications, like web scripts). - For almost any complex data, it becomes immediately less useful, but with a small amount of external wrapping, can also be used for more complex configuration structures. - It is *not* a means for declaring objects or doing sums: that is what the Python syntax itself is for. My problems with the current ConfigParser are as follows: - The interface is unfriendly and error-prone. Examples: - read(): raises no exception if a file is missing. This is against Python culture, and the unsurprising name causes IMHO surprising behaviour, especially for the standard library. - readfp(): 'more than one way to do it'. File-like objects are such a fundamental part of Python that I think read() should go away entirely. This would mean that a programmer is explicitly reminded of the errors that can occur when opening his configuration file as he explicitly types the file() factory expression himself. - Again, for getting values there are a few methods which essentially repeat themselves - getint(), getfloat(), etc. What is wrong with int(obj.get(...))? - get() shares the same method name as the infinitely popular dict.get() method, yet does not support a <default> argument. - String interpolation! There is a friendly string syntax as a standard library feature these days, and less friendly interpolation has always existed in the language itself. This should go, and be made more explicit for the programmer. In my opinion we should differenciate at an early stage between complex processing tasks (Python itself) and storing random snippets of configuration data. In short, removing the functions that really shouldn't be there and modernizing the code, would be a good starting place for a replacement. Only then we can start talking about ConfigParser-NG. Thanks, David. -- Now that my house has burned down I have a much better view of the moon.