homepage

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.

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?

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.

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.

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 

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.

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