Ian Bicking wrote: > Guido van Rossum wrote: > >>> I don't think enhancing ConfigParser significantly is a good way >>> forward. Because of ConfigParser's problems people have made all sorts >>> of workarounds, and so I don't think there's any public interface that >>> we can maintain while changing the internals without breaking lots of >>> code. In practice, everything is a public interface. So I think the >>> implementation as it stands should stay in place, and if anything it >>> should be deprecated instead of being enhanced in-place. >>> >> Somehow that's not my experience. What's so bad about ConfigParser? >> What would break if we rewrote the save functionality to produce a >> predictable order? >> > > That's a fairly minor improvement, and I can't see how that would break > anything. But Michael (aka Fuzzyman -- sorry, I just can't refer to you > as Fuzzyman without feeling absurd ;) Don't worry, absurdity is a common reaction I inspire in people. Actually Fuzzyman is more of a description than a nickname. I understand that I may not be the only one worthy of such a title of course. ;-)
> was proposing ConfigObj > specifically (http://www.voidspace.org.uk/python/configobj.html). I > assume the internals of ConfigObj bear no particular resemblence to > ConfigParser, even if ConfigObj can parse the same syntax (plus some, > and with different failure cases) and provide the same public API. > > While ConfigParser is okay for simple configuration, it is (IMHO) not a > very good basis for anyone who wants to build better systems, like > config files that can be changed programmatically, or error messages > that point to file and line numbers. Those aren't necessarily features > we need to expose in the standard library, but it'd be nice if you could > implement that kind of feature without having to ignore the standard > library entirely. > > Can you elaborate on what kinds of programattic changes you envisage ? I'm just wondering if there are classes of usage not covered by ConfigObj. Of course you can pretty much do anything to a ConfigObj instance programattically, but even so... > That said, I'm not particularly enthused about a highly featureful > config file *format* in the standard library, even if I would like a > much more robust implementation. > > I don't see how you can easily separate the format from the parser - unless you just leave raw values. (As I said in the other email, I don't think I fully understand you.) If accessing raw values suits your purposes, why not subclass ConfigParser and do magic in the get* methods ? > From my light reading on ConfigObj, it looks like it satisfies my > personal goals (though I haven't used it), but maybe has too many > features, like nested sections. And it seems like maybe the API can be > I personally think nested sections are very useful and would be sad to not see them included. Grouping additional configuration options as a sub-section can be *very* handy. > reduced in size with a little high-level refactoring -- APIs generally > grow over time so as to preserve backward compatibility, but I think if > it was introduced into the standard library that might be an opportunity > to trim the API back again before it enters the long-term API freeze > that the standard library demands. Hmmm.... possibly. :-) walk, decode and encode are the obvious extraneous methods. walk can be re-implemented as a recursive function and encode/decode will be unnecessary when unicode support is complete. Additional complexity comes from retaining all comments and supporting validation. I think retaining comments is worthwhile, because it allows a program to modify a config file (e.g. from a GUI) without losing user comments in a handwritten config file. The validation support has several levels to it - but it can be completely ignored with no complexity for the user. Some validation support is integrated into instantiation, but this could *probably* be broken out into a subclass. Anyway, ho hum - possibly. All for future hypothetical discussion I guess... All the best, Fuzzyman http://www.voidspace.org.uk/python/configobj.html _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com