Fred L. Drake, Jr.
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>