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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4