Case sensitivity bug in ConfigParser?

[asqui]

(Assume an instantiated ConfigParser, c, with a loaded file)
>>> c.get("DEFAULT", "foo", False, {"foo": "Bar"})
'Bar'

>>> c.get("DEFAULT", "Foo", False, {"Foo": "Bar"})
Traceback (most recent call last):
  File "<pyshell#70>", line 1, in ?
    c.get("DEFAULT", "Foo", False, {"Foo": "Bar"})
  File "C:\Python23\lib\ConfigParser.py", line 513, in get
    raise NoOptionError(option, section)
NoOptionError: No option 'foo' in section: 'DEFAULT'


The offending code appears to be as follows (in ConfigParser.py):
    def get(self, section, option):
        opt = self.optionxform(option)
        if section not in self._sections:
            if section != DEFAULTSECT:
                raise NoSectionError(section)
            if opt in self._defaults:
                return self._defaults[opt]
            else:
                raise NoOptionError(option, section)
        elif opt in self._sections[section]:
            return self._sections[section][opt]
        elif opt in self._defaults:
            return self._defaults[opt]
        else:
            raise NoOptionError(option, section)

It uses optionxform on the supplied option, but not on the one in the
defaults dictionary. If you're going to impose a transform then you
have to do it consistently, imho...

>>> c.get("DEFAULT", "Foo", False, {"foo": "Bar"})
'Bar'

The supplied "Foo" gets transformed to "foo" and matches the one in
the defaults dictionary.

Seems a bit counterintuitive to expect that you supply any defaults as
pre-transformed according to your specified optionxform.

I'm not sure if this is also a problem when reading a file, but there
seems to be a related post about this (with no replies!) dating back
to 2000 http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=8suc1f%24mf9%241%40nnrp1.deja.com

I don't have time to look into it now but I'd guess this problem was
resolved in the more obvious location (when reading a file) but
patching of the defaults dictionary case was omitted.


asqui