[Python-Dev] Re: ConfigParser changes

[Eric S. Raymond]

Fred L. Drake, Jr. <fdrake@acm.org>:
> 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.

On my to-do list.
 
> 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.

Guido has already made this point.

As a matter of taste, I like the serialization operation to be
separate from I/O.  I think that's cleaner, and in this case the
in-memory string is unlikely to get large.  But I don't actually need
this change, so I won't argue for it against opposition.

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

No.  But comments are fair game to be discarded, since they're not part
of the data content.  In my use case they're not important.
  
> 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.

A fair point.  I would be happy to change the interface away from a magic
member to a real method.  Likewise for the structured-value stuff.
 
> 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.  ;-)

Then we shouldn't try.  Let's not let the ideal be the enemy of the good
here; the multiline-literal syntax is othorgonal to how we handle 
string encoding, and internationalization can be layered on it later.
 
>  > 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.

I'm taking suggestions on how to do it right.  I don't think there's any
obviously better way than what I've implemented, except maybe for making the
trigger a real method rather than a magic member.

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

Right, because I needed it.
 
> 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.

I had this conversation with Guido a couple years back.  I too would have
been happier with two classes, one read-only and one that supports writing
back out.  Here is whatt Guido said and I replied:

---------------------------------------------------------------------------
Guido van Rossum <guido@beopen.com>:
> One possible suggestion (just for your contemplation): if you're only
> adding methods, would it make sense to make a subclass, so that from
> the class one uses it is clear whether one intends to modify the
> options or just to read them?  That would enable future optimizations.

Yes, and I even know what I'd call the class: ConfigEditor.

Unfortunately this plan it trips on a historical fact; one (1) of the
write methods, add_section(), already existed in ConfigParser.  Moving
it to a ConfigEditor subclass would break backward compatibility.  And
I think it would be just too ugly to move all but one of the write
methods into ConfigEditor and leave add_section() in the base class.

If not for this problem I would be more than happy to do as you suggest.
---------------------------------------------------------------------------

Guido dropped the thread, which I took to mean that he saw the force
of the objection.  But I'd *still* like to do as he suggested.  

If the consensus is that its OK to deprecate add_section() and write()
in the base class, I'll write ConfigEditor and move all my surgery
stuff over there in a heartbeat.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>