Eric S. Raymond writes:
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 don't think they're fair game if we want a surgical implementation. Neither are blank lines.
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.
The question of exactly where to draw the line has bit us so many times with ConfigParser that I'm quite wary. I'll leave it for others to determine whether I'm too much so.
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.
I'm not suggesting that there's a better way, only a precedent.
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:
[long quotation elided]
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.
I think add_section() is useful for modifying an in-memory configuration (perhaps loaded from multiple sources, other than INI files). The implementation would be different than for your proposed ConfigEditor, but that's OK. write() may also be useful for other reasons, and probably isn't worth deprecating. Maintenance of those methods is not a good reason to create a separate ConfigEditor class. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation