ConfigParser generating strings I can't compare

[lpangelrob]

BPO	1234965
Nosy	@tim-one

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2005-07-08.20:57:21.000>
created_at = <Date 2005-07-08.20:50:34.000>
labels = ['invalid', 'library']
title = "ConfigParser generating strings I can't compare"
updated_at = <Date 2005-07-08.20:57:21.000>
user = 'https://bugs.python.org/lpangelrob'

bugs.python.org fields:

activity = <Date 2005-07-08.20:57:21.000>
actor = 'tim.peters'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2005-07-08.20:50:34.000>
creator = 'lpangelrob'
dependencies = []
files = []
hgrepos = []
issue_num = 1234965
keywords = []
message_count = 2.0
messages = ['25767', '25768']
nosy_count = 2.0
nosy_names = ['tim.peters', 'lpangelrob']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1234965'
versions = []

[lpangelrob]

This is better demonstrated than described:

Assume the following "myconfig.cfg" in the current
directory...

[main]
OPT=no
<newline>

The following occurs from the command line:

Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32
bit (Intel)] on win32
<snip>
>>> from ConfigParser import ConfigParser
>>> p = ConfigParser()
>>> p.read('myconfig.cfg')
['myconfig.cfg']
>>> configWord = p.get('main','OPT')
>>> configWord
'no'
>>> word = 'no'
>>> word
'no'
>>> configWord is word
False
>>> word2 = 'no'
>>> word2
'no'
>>> word2 is word
True
>>> len(word)
2
>>> len(configWord)
2
>>> type(configWord)
<type 'str'>
>>> type(word)
<type 'str'>

In other words, the config values ConfigParser
generates look a lot like strings, have types like
strings, and have the same lengths as strings, but
can't be compared as strings. This smells like a bug.

[tim-one]

Logged In: YES
user_id=31435

You should never use "is" to compare strings for equality
(unless you have deep knowledge of what you're doing, and
your application code guarantees to use unique string
objects). Use "==" instead.

For more about when you can and can't rely on "is", please
start a discussion on comp.lang.python (or use Google to
find the many previous discussions). It's not "a bug", and
won't change.