[Python-Dev] ConfigParser changes
Eric S. Raymond
Tue, 31 Dec 2002 11:57:01 -0500
Fred L. Drake, Jr. <firstname.lastname@example.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
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>