Case sensitivity bug in ConfigParser?

[asqui]

(Assume an instantiated ConfigParser, c, with a loaded file)

'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...
'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&[email protected]

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