This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Case sensitivity bug in ConfigParser
Type: Stage:
Components: Library (Lib) Versions: Python 2.4
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: fdrake Nosy List: asqui, fdrake, goodger
Priority: high Keywords:

Created on 2004-08-27 20:26 by asqui, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
ConfigParser.py.1017864.diff goodger, 2004-09-23 14:19 patch for Lib/ConfigParser.py
test_cfgparser.py.1017864.diff goodger, 2004-09-23 14:22 patch for Lib/test/test_cfgparser.py
Messages (5)
msg22246 - (view) Author: Dani (asqui) Date: 2004-08-27 20:26
(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.
msg22247 - (view) Author: David Goodger (goodger) (Python committer) Date: 2004-09-23 14:19
Logged In: YES 
user_id=7733

Patches added for ConfigParser.py and test_cfgparser.py.
msg22248 - (view) Author: David Goodger (goodger) (Python committer) Date: 2004-09-23 14:22
Logged In: YES 
user_id=7733

Should be applied prior to 2.4-beta-1.
msg22249 - (view) Author: David Goodger (goodger) (Python committer) Date: 2004-10-03 16:03
Logged In: YES 
user_id=7733

Applied the patches in CVS.
This is a Python 2.3 backport candidate.

Lib/ConfigParser.py 1.68
Lib/test/test_cfgparser.py 1.25
Doc/lib/libcfgparser.tex 1.39
msg22250 - (view) Author: David Goodger (goodger) (Python committer) Date: 2004-10-03 16:05
Logged In: YES 
user_id=7733

correction:

Lib/ConfigParser.py 1.67
Lib/test/test_cfgparser.py 1.24
no change to Doc/lib/libcfgparser.tex
History
Date User Action Args
2022-04-11 14:56:06adminsetgithub: 40836
2004-08-27 20:26:54asquicreate