Ian Bicking wrote: > Fuzzyman wrote: >> The resolution I'm suggesting means that people can continue to use >> ConfigParser, with major feature enhancements. *Or* they can migrate >> to a slightly different API that is easier to use - without needing >> to switch between incompatible modules. > > 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. > > Another class or module could be added that fulfills the documented > interface to ConfigParser. This would provide an easy upgrade path, > without calling it a backward-compatible interface. I personally > would like if any new config system included a parser, and then an > interface to the configuration that was read (ConfigParser is only the > latter). Then people who want to do their own thing can work with just > the parser, without crudely extending and working around the > configuration interface. > But to implement a parser you still need to agree a basic syntax.
For example ConfigObj supports list values, handles quotes sanely, uses triple quotes for multiline values, allows inline comments, and has a syntax for nested sections. Once you have agreed these and a *basic* API spec for accessing the data then you've implemented most of your config file handler. In order to implement a write (save) method you also have to agree on how to handle non string values (like lists). There's not an *awful* lot left to do. In ConfigObj if you switch off list handling when parsing and interpolation when fetching values, you have access to the raw values and are free to extend value handling any way you choose. In my opinion dictionary syntax is the most natural way to represent a config file - it is a data structure with named members. This means the API for accessing the data - whether from a subclass that does additional value processing or from code that just accesses the data. I may be misunderstanding you of course (or more likely not fully understanding). :-) All the best, Fuzzyman http://www.voidspace.org.uk/python/index.shtml _______________________________________________ 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
