[Python-Dev] What are the goals for ConfigParser 3000?
dw-python.org at botanicus.net
Wed Oct 20 16:18:13 CEST 2004
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
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
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.
Now that my house has burned down I have a much better view of the moon.
More information about the Python-Dev