ConfigParser does not implement "comments need to be preceded by a whitespace character" correctly and in most cases will treat a value beginning with a comment character as a comment, even though it is not preceded by a whitespace character.

The ConfigParser documentation states:
"""
Comments may appear on their own in an otherwise empty line, or may be entered in lines holding values or section names. In the latter case, they need to be preceded by a whitespace character to be recognized as a comment.
"""

This suggests that in the following configuration file, the value of 'password' would be read as ';23bUx1'.

[test_config]
password=;23bUx1
username=bar

In fact, there appears to be a bug in the following code within RawConfigParser._read():

    if vi in ('=', ':') and ';' in optval:
        # ';' is a comment delimiter only if it follows
        # a spacing character
        pos = optval.find(';')
        if pos != -1 and optval[pos-1].isspace():
            optval = optval[:pos]
    optval = optval.strip()

For the example file above, vi==';' and optval==';23bUx1\r'. pos therefore takes the value 0, and the second part of the compound if statement which checks if the preceding character is a space ends up looking at optval[-1] -- the last character in optval -- which is \r, since it has not yet been stripped.

I think this can be resolved by changing the line:
    if pos != -1 and optval[pos-1].isspace():
to:
    if pos > 0 and optval[pos-1].isspace():

Thus, the "if preceded by a space" case is only considered if the comment character appears *after* the first character in the value. (And if it appears as the very *first* character, then by definition it cannot be preceded by a space!)

A rather fragile workaround (which works only if there is only one single value affected by this bug) would be to ensure that the affected value is defined on the last line of your config file, the file does not end with a carriage return. In this case, the optval[-1] would return a non-whitespace character and prevent the value being considered a comment.

The above analysis pertains to Python 2.7.2, and I see that the implementation has been re-written in python 3 so this bug doesn't seem to exist there.