[Python-Dev] Changes to ConfigParser

Greg Stein gstein@lyra.org
Mon, 10 Jul 2000 15:33:14 -0700


On Mon, Jul 10, 2000 at 04:28:55PM -0400, Eric S. Raymond wrote:
> Earlier today, I committed a patch to ConfigParser that adds three new
> methods to the class.  Here is the documentation:

Excellent! I have a few subclasses of ConfigParser that do these things,
too. Glad to see it in the standard distro :-)

>...
> These new methods are additions to the class, and do not change any
> existing code.  Nevertheless Guido sent me a heads-up that I had 
> committed a marginal violation of Python etiquette by changing the
> module without the explicit sign-off of the maintainers.

<IMO-about-culture>

API changes probably ought to be discussed on this list (which includes the
maintainers of any code). Basic point: the "maintainer(s)" is usually quite
unclear since we avoid attribution within the source if at all possible.
Posing the suggested change here allows for changing maintainers (note that
Fred has done a tone of work on ConfigParser, and I've submitted a few
changes myself, too!), and it allows for broader input.

However, bug fixes and minor reworking should probably be allowed regardless
of the maintainer. I'd hate to end up at a point where the Python
interpreter is partitioned into a bunch of little fiefdoms, where you must
pay a toll to enter.

</IMO-about-culture>

>...
> Two more things remain to be done:
> 
> First, for completeness there ought to be remove_section and remove_option
> methods (though forgetool does not yet use them).  I have documented these
> as follows:

+1

>...
> Second, the new methods expose a bug in the existing code.  Because
> the case of section and option names is folded on input, the new
> write() method emits edited configurations with their case smashed.  I
> think the existing code should be fixed to preserve case, with
> string.lower() being applied at key lookup time.

+1

The string.lower() at lookup time shifts the performance response, but I
don't really see config state as performance-intensive.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/