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. -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
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