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>