On Sat, Apr 26, 2014 at 7:23 AM, Steven D'Aprano <st...@pearwood.info> wrote:
> But the entry in question wasn't a line, it was a key=value pair in a
> dict. Here's that line again:
>
> cp.read_dict({'DEFAULT': {';foo': 'bar'}})
>
> or it could have been:
>
> cp['DEFAULT'][';foo'] = 'bar'
>
> Either way, if there's no way to escape comment characters, I think it
> is a bug that you can insert illegal keys into the cp object in the
> first place.
Fair enough.
I'm not trying to argue that it isn't a bug, but that risk of breaking
currently-working applications with data they consider acceptable is
high. Many use configparser for input only, and make no use of the
serialization feature. Those applications can be broken by adding a
constraint on the data that's allowed, regardless of what we think of
their keys.
Chaning this in an application for which it's safe (easier to know at
the application level) is easy enough:
import configparser
import re
class ProtectionistParser(configparser.RawConfigParser):
_rx = re.compile(r"[a-z]([-a-z]*[a-z])?$") # or whatever
makes sense for your app
def optionxform(self, opt):
if self._rx.match(opt) is None:
raise ValueError("don't like this: %r" % opt)
return opt
Maybe the "strict" mode is considered new enough that this isn't as
significant a risk, and it could be allowed when that's enabled; I'm
sure Łukasz will have a carefully considered opinion (and I'll defer
to him in the end).
-Fred
--
Fred L. Drake, Jr. <fred at fdrake.net>
"A storm broke loose in my mind." --Albert Einstein
_______________________________________________
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
