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