On 04/25/2014 11:54 AM, Fred Drake wrote: > On Fri, Apr 25, 2014 at 2:45 PM, Terry Reedy <tjreedy at udel.edu> wrote: >> I leave it to someone to carefully read the doc, but a brief glance >> indicates "There are nearly as many INI format variants as there are >> applications using it. configparser goes a long way to provide support for >> the largest sensible set of INI styles available." So I wonder whether the >> thought-to-be-buggy behavior is actually buggy with respect to *all* the >> supported styles or just some of them. > > Given that most variants are completely undocumented, answering this > is sufficiently intractable for me to call it intractable. > > We've also run into compatibility issues because some applications > treated the "parser" object as an in-memory configuration database > throughout the process lifetime, updating values with non-string > values of various sorts. Given the age of the module, the existing > number of uses of undocumented accidents of implementation is very > large. Fixing "bugs" like this has an excellent track record of > uncovering these uses, so... we've grown a bit wary. It's not unheard > of for projects to fork their own copies of configparser because of > changes to the stdlib version. (No, I haven't done a census of such > cases, but I do know of at least one in a popular package.) Seems reasonable. Perhaps an enhancement request then: a way to provide a regex that keys must match, with an exception raised when a key doesn't. That way the safety belt could be used when desired. -- ~Ethan~
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