[Python-Dev] What are the goals for ConfigParser 3000?

[David Wilson]

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.