Guido van Rossum writes: > - You could put it all in ConfigParser.py but with new classnames. > (Not sure though, since the ConfigParser class, which is really a > kind of weird variant, will be assumed to be the main class because > its name is that of the module.) The ConfigParser class could be clearly marked as deprecated both in the source/docstring and in the documentation. But the class itself should not be used in any way. > - Variants on the syntax could be given through some kind of option > system rather than through subclassing -- they should be combinable > independently. Som possible options (maybe I'm going overboard here) > could be: Yes, you are going overboard. It should contain exactly what's right for .ini files, and that's it. There are really three aspects to the beast: reading, using, and writing. I think there should be a class which does the right thing for using the informatin in the file, and reading & writing can be handled through functions or helper classes. That separates the parsing issues from the use issues, and alternate syntaxes will be easy enough to implement by subclassing the helper or writing a new function. An "editable" version that allows loading & saving without throwing away comments, ordering, etc. would require a largely separate implementation of all three aspects (or at least the reader and writer). > (Well maybe the whole substitution thing should really be done through > a subclass -- it's too weird for normal use.) That and the ad hoc syntax are my biggest beefs with ConfigParser. But it can easily be added by a subclass as long as the method to override is clearly specified in the documenation (it should only require one!). -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives
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