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