Home Original page

[Python-Dev] ConfigParser mangles keys with special chars

Fred Drake fred at fdrake.net
Sat Apr 26 17:32:18 CEST 2014 
On Sat, Apr 26, 2014 at 7:23 AM, Steven D'Aprano <steve at 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
More information about the Python-Dev mailing list