[Python-Dev] ConfigParser changes

[Eric S. Raymond]

Fred L. Drake, Jr. <fdrake@acm.org>:
> Regarding Eric's changes, I'd like to see them discussed before being
> made part of the library; the interface seems quite ad hoc, and it's
> not clear that they are the right way to go about adding sequence
> support.

Do you have the same reaction to the multiline string support?

And do you want the line-continuation bugfix?

> The value of having __str__() return a parsable INI file is highly
> questionable; the motivation should be explained and discussed.

Cleanliness.  I believe in invertible representations.  Whenever I write
a class, I like to have its str() or repr() emit something parseable.
If nothing else, this is useful for debugging.  This is just general
principles, I don't (unlike my other changes) have a use case for it.

> The issue of ordering sections and options in the same way as the input
> seems unimportant as well; comments are lost anyway.  Being able to
> surgically edit a config file using the ConfigParser module is simply
> not a supported use case.

It is now.  That was the point of the enhancements.

> I'll be reverting the change shortly.  Eric, I would like to encourage
> you to pursue this functionality via discussion on python-dev with the
> patch submitted via SourceForge.  The functional extensions are not
> unwelcome by any means.

OK.  Then let the discussion begin.  Here are the issues:

1. There is a minor bug in the way continuations are handled that, in
some circumstances, can mean the write() representation is not invertible.

2. Currently ConfigParser cannot support multiline strings -- that is, values
that are multiline and have embedded whitespace.  I need this capability.
I added support for this through a class member that lets you declare string 
quotes.  Is there some objection to supporting this value type, or just to
the magic-class-member interface?

3. Currently ConfigParser cannot support structured values. Again, I
need this capability (for association lists of coordinates and names,
as it happens).  The syntax I have implemented is a configurable list
bracket character surrounding comma-separated lists.  The alternative
Fred suggests is, I think, extremely ugly.  If anyone has a more
natural suggestion than my proposal, I'm willing to hear it.

4. I *do* in fact want to support `surgical' alteration of .INI files.
I have a use case for this in a configuration editor I'm writing for
FreeCiv.  More generally, when writing code to support invertible
representations, I think it is good citizenship to perturb the
original data as little as possible.  Thus I regard the fact that 
the present code permutes options and sections into an arbitrary 
order dependent on the hash table implementation as a design bug, and
actually a fairly serious sort of thoughtlessness.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>