ConfigParser shootout, preliminary entry

Carlos Ribeiro carribeiro at
Sat Oct 23 18:12:25 CEST 2004

On Sat, 23 Oct 2004 10:46:24 -0400, Peter Hansen <peter at> wrote:
> David Wilson wrote:
> > NAME
> >     ConfigParser - Configuration file parser.
> >
> > The 'config' object you refer to does not appear to be implemented by
> > the ConfigParser module.
> Ah, there's the conflict.  For the simpler stuff I'm picturing,
> I don't have a *separate* parser which serves solely to
> read the file and return the information therein in a form
> that requires a different object to preserve and provide later
> access to it.  I bundle those babies together so, in my mind
> and despite seeing the name and reading your various comments
> repeatedly, it wasn't clear to me that we were implicitly (?)
> leaving out all other issues of configuration, leaving only
> the tiny parsing bit.

I agree with Peter -- that's the whole point of this discussion. The
question can be re-stated as, "do we need a configuration object or a
configuration parser object"? The former is able to read/write itself
from a text file (using INI, or other suitable format); the latter
only reads a INI file and parses it.

In my opinion, we don't have really to make a choice or a concession
here. A simple parser can be provided, using a simple interface as the
one defended by David; and a wrapper implementing the "configuration
object" can also be provided, using class-based access. Similar
examples of this layered approach already exist in the library. You
just build it upon the standard blocks available. Of course, (and with
all due respect) it does not address one David's arguments, that -- as
far as I understood it -- sees the extended attribute access syntax
for configuration objects as non-natural and therefore unwarranted in
Python. That's a valid opinion, and I'm not going to try to convince
anyone here about which way is better. But seeing these two issues as
separate things *is* a good step.

Carlos Ribeiro
Consultoria em Projetos
mail: carribeiro at
mail: carribeiro at

More information about the Python-list mailing list