[Python-Dev] Re: ConfigParser changes

[Fred L. Drake, Jr.]

Eric S. Raymond writes:
 > Do you have the same reaction to the multiline string support?

Yes.  It should definately be discussed.

 > And do you want the line-continuation bugfix?

That would be nice to have; I should have responded to that point
separately.  Feel free to commit a minimal patch to fix that, and add
a regression test to Lib/test/test_cfgparser.py.

 > > 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.

I don't think it's clear that using __str__() for this is valuable.
Creating a potentially large string in memory may not be the best
approach; I actually like the write() method better; the caller can
decide to use a StringIO if that's what makes sense, or toss things to
a real file if needed.

If others like this, I won't object.  It should be a separate patch
from the other changes, though.

 > > 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.

Perhaps I missed it; did you preserve comments as well?

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

Excellent!  Thanks.

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

Per above, that can be fixed at any time.  Bugs are written to be
squashed.  ;-)

 > 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?

I think the interface should be discussed; your implementation may be
sufficient, but after working with pyexpat as much as I have, I've
developed a strong dislike for attributes that have substantial side
effects.

If we're going to add a special syntax for multi-line values, we may
need to think about encoding special values, text encoding, and
Unicode.  And that's never easy to get concensus on.  ;-)

 > 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.

I think "suggests" is too strong a word; I was only citing precedence,
not advocating that approach.  I think it's pretty ugly as well.

 > 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

I think there's a distinction between reading a configuration and
editing it:  The original code never wrote a file back out.  That was
something you added in revision 1.19.

 > 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.

Only if you write the file back out.  ;-)

Seriously, I have no objection to supporting surgical editing.  I do
think that separate classes should be used for read-only uses and
read-write uses; a read-only ConfigParser-thingie should remain very
lightweight, and surgical editing just isn't that.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation