On 04/25/2014 11:54 AM, Fred Drake wrote:
On Fri, Apr 25, 2014 at 2:45 PM, Terry Reedy <tjre...@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~
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to