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: ConfigParser doesn't strip inline comment when delimiter occurs earlier without preceding space.
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: lukasz.langa Nosy List: eric.araujo, grahamd, lukasz.langa, python-dev
Priority: normal Keywords:

Created on 2012-04-16 01:57 by grahamd, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
test_config.py grahamd, 2012-04-16 01:57 Test of incorrect inline comment parsing.
Messages (7)
msg158397 - (view) Author: Graham Dumpleton (grahamd) Date: 2012-04-16 01:57
When parsing for inline comments, ConfigParser will only check the first occurrence of the delimiter in the line. If that instance of the delimiter isn't preceded with a space, it then assumes no comment. This ignores the fact that there could be a second instance of the delimiter which does have a preceding space. The result is that inline comments can be left as part of the value.

So, a config file of:

[section]
value1 = a;b
value2 = a ; comment
value3 = a; b ; comment

after parsing actually results in:

[section]
value1 = a;b
value2 = a
value3 = a; b ; comment

That is, 'value3' is incorrect as still embeds the inline comment.

Test script attached for Python 2.X.

Not tested on Python 3.X but code appears to do the same thing, except that on Python 3.X inline comments are disabled by default.
msg158612 - (view) Author: Łukasz Langa (lukasz.langa) * (Python committer) Date: 2012-04-18 12:49
While this bug is real, I'm hesitant to fix it for 2.7 and 3.2. I can imagine someone using the current behaviour unintentionally, and getting burned by the fix. This would be a real PITA to debug.

Is it fine by you if I just fix it for 3.3 and update the backport?
msg158674 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-04-18 22:11
I don’t remember if the doc is precise or not about this behavior, but I’m convince people used trial-and-error to see what exactly configparser would do, and rely on that knowledge know.  I think I had to do that once.  Thus it is not clear to me that changing the default behavior in 3.3 is a good idea.
msg158702 - (view) Author: Łukasz Langa (lukasz.langa) * (Python committer) Date: 2012-04-19 07:27
INI files won't go away and there will come a time where 3.3 is old. Since 3.2 inline comments are turned off by default which mitigates the problem. Fixing this parser bug for the 3.3 release seems safe enough for me as long as you clearly state in NEWS and the docs that it changed. I'll leave 2.7 and 3.2 behind as to my doubts stated in the previous comment.
msg164911 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2012-07-07 16:59
New changeset 5257bb466d18 by Łukasz Langa in branch 'default':
Fixes #14590: ConfigParser doesn't strip inline comment when delimiter occurs
http://hg.python.org/cpython/rev/5257bb466d18
msg164963 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-07-08 04:16
If this is a bugfix, can you backport it to stable branches?  If it’s a new, incompatible behavior change, then it was committed too late for 3.3 in theory.
msg178793 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2013-01-02 00:03
New changeset d5c45089df2d by Łukasz Langa in branch '3.3':
Misc/NEWS updated to tell about #14590 and #16820
http://hg.python.org/cpython/rev/d5c45089df2d
History
Date User Action Args
2022-04-11 14:57:29adminsetgithub: 58795
2013-01-02 00:03:42python-devsetmessages: + msg178793
2012-07-08 04:16:56eric.araujosetmessages: + msg164963
2012-07-07 17:00:08lukasz.langasetstatus: open -> closed
resolution: fixed
stage: resolved
2012-07-07 16:59:16python-devsetnosy: + python-dev
messages: + msg164911
2012-04-19 07:27:09lukasz.langasetmessages: + msg158702
versions: - Python 2.7, Python 3.2
2012-04-18 22:11:04eric.araujosetnosy: + eric.araujo
messages: + msg158674
2012-04-18 12:49:52lukasz.langasetmessages: + msg158612
2012-04-16 02:18:38r.david.murraysetversions: - Python 2.6, Python 3.1
2012-04-16 02:18:19r.david.murraysetassignee: lukasz.langa

nosy: + lukasz.langa
2012-04-16 01:57:47grahamdcreate