[Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib ConfigParser.py,1.16,1.17

[Fred L. Drake, Jr.]

Jeremy Hylton writes:
 > Thanks for catching that.  I didn't look at the context.  I'm going to
 > wait, though, until I talk to Fred to mess with the code any more.

  I did it that way since the .ini format allows comments after values 
(the ';' comments after a '=' vi; '#' comments are a ConfigParser
thing), but there's no equivalent concept for RFC822 parsing, other
than '(...)' in addresses.  The code was trying to allow what was
expected from the .ini crowd without breaking the "native" use of
ConfigParser.

 > General question for python-dev readers: What are your experiences
 > with ConfigParser?  I just used it to build a simple config parser for
 > IDLE and found it hard to use for several reasons.  The biggest
 > problem was that the file format is undocumented.  I also found it
 > clumsy to have to specify section and option arguments. I ended up
 > writing a proxy that specializes on section so that get takes only an
 > option argument.
 > 
 > It sounds like ConfigParser code and docs could use a general cleanup.
 > Are there any other issues to take care of as part of that cleanup?

  I agree that the API to ConfigParser sucks, and I think also that
the use of it as a general solution is a big mistake.  It's a messy
bit of code that doesn't need to be, supports a really nasty mix of
syntaxes, and can easily bite users who think they're getting
something .ini-like (the magic names and interpolation is a bad
idea!).  While it suited the original application well enough,
something with .ini syntax and interpolation from a subclass would
have been *much* better.
  I think we should create a new module, inilib, that implements
exactly .ini syntax in a base class that can be intelligently
extended.  ConfigParser should be deprecated.


  -Fred

--
Fred L. Drake, Jr.	  <fdrake at acm.org>
Corporation for National Research Initiatives