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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4