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.

Unsupported provider

classification
Title: Support for non-string data in ConfigParser unclear/buggy
Type: Stage:
Components: None Versions: Python 2.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: fdrake Nosy List: fdrake, goodger, kirbysdl
Priority: normal Keywords:

Created on 2003-09-22 21:58 by kirbysdl, last changed 2022-04-10 16:11 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
config_example.py kirbysdl, 2003-09-22 21:58 Example of using an integer as a ConfigParser option's value
Messages (3)
msg18257 - (view) Author: curby (kirbysdl) Date: 2003-09-22 21:58
In my current project, I'm using ConfigParser to read
configuration files as well as manage internal
configuration.  The following test script generates an
error because values of options must be strings in
order for ConfigParser to run smoothly.  (It's short
enough that I'm including it here for reference; I'm
also attaching it).

#----- BEGIN TEST -----
#!/usr/bin/env python

import ConfigParser
import sys

conf = ConfigParser.ConfigParser()
conf.add_section("sect")
conf.set("sect","option",2)
conf.write(sys.stderr)
conf.get("sect","option")
#----- END TEST -----

From the ConfigParser code, I see that the value isn't
checked to make sure it is a string before string
methods are applied to it.

I'm currently using the raw parameter to get() (see
http://www.python.org/doc/lib/ConfigParser-objects.html#l2h-1261)
in order to circumvent the problem.

I'd suggest one or more of the following:
(1) Casting the option to a string explicitly instead
of assuming it is a string (this could also be done in
the set() method).
(2) Checking that the option is a string instead of
assuming it is a string.
(3) Stating in the documentation that the set() method
should only take values of type string.
(4) Stating in the documentation that the raw parameter
should be used when an option's value might not be of
type string (this might be the intended usage, but it
isn't made clear).

I hope none of these are too difficult to implement,
but I understand that this is a noncritical problem. 
Nonetheless, I was shocked to see what I thought was a
straightforward use of ConfigParser throw off errors.  
msg18258 - (view) Author: Fred Drake (fdrake) (Python committer) Date: 2004-05-18 03:32
Logged In: YES 
user_id=3066

Fixed using methods (2) and (3):  ConfigParser.set() now
checks that the value is some flavor of string, and raises
TypeError if it isn't.  This is documented behavior;
regression tests have been added.

Doc/lib/libcfgparser.tex 1.36
Lib/ConfigParser.py 1.65
Lib/test/test_cfgparser.py 1.22
msg18259 - (view) Author: David Goodger (goodger) (Python committer) Date: 2004-10-03 16:15
Logged In: YES 
user_id=7733

FYI: Moved the new type-check to SafeConfigParser.set(); see
http://www.python.org/sf/997050.

Lib/ConfigParser.py 1.68
Lib/test/test_cfgparser.py 1.25
Doc/lib/libcfgparser.tex 1.39
History
Date User Action Args
2022-04-10 16:11:17adminsetgithub: 39273
2003-09-22 21:58:21kirbysdlcreate