On Fri, 3 Mar 2000, Jeremy Hylton wrote:
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.
Not a problem. I'm glad that diffs are now posted to -checkins. :-)
General question for python-dev readers: What are your experiences with ConfigParser?
Love it!
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.
In my most complex use of ConfigParser, I had to override SECTCRE to allow periods in the section name. Of course, that was quite interesting since the variable is __SECTRE in 1.5.2 (i.e. I had to compensate for the munging). I also change OPTCRE to allow a few more charaters ("@" in particular, which even the update doesn't do). Not a problem nowadays since those are public. My subclass also defines a set() method and a delsection() method. These are used because I write the resulting changes back out to a file. It might be nice to have a method which writes out a config file (with an "AUTOGENERATED BY ConfigParser.py -- DO NOT EDIT BY HAND"; or maybe "... BY <appname> ...").
I also found it clumsy to have to specify section and option arguments.
I found these were critical in my application. I also take advantage of the sections in my "edna" application for logical organization.
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?
A set() method and a writefile() type of method would be nice. Cheers, -g -- Greg Stein, http://www.lyra.org/