Skip to content

configparser: whitespace-ending delimiter with an empty value cannot be parsed (write() output is unreadable) #157456

Description

@winklemad

Bug report

The whitespace-in-delimiters feature added in gh-156353 (3.16) cannot parse an option that has an empty value when the delimiter ends in whitespace — including its own write() output.

_read matches option lines against line.clean, which is val.strip() (both sides) with comments removed. For a whitespace delimiter, the delimiter is the trailing whitespace, so strip() erases it and OPTCRE no longer matches.

Reproduction (on main, 3.16.0a0)

import configparser, io

# (1) plain read — rejected, though the option regex itself matches "key ":
cp = configparser.ConfigParser(delimiters=(' ',))
cp.read_string("[s]\nkey \n")          # -> ParsingError   (expected: {'key': ''})

# (2) round-trip — write() emits a line read_string() then refuses to parse:
w = configparser.ConfigParser(delimiters=(' ',)); w['s'] = {'key': ''}
buf = io.StringIO(); w.write(buf)
print(repr(buf.getvalue()))            # '[s]\nkey   \n\n'
configparser.ConfigParser(delimiters=(' ',)).read_string(buf.getvalue())  # ParsingError

A serializer that cannot read its own output is a clear self-inconsistency. Empty values are a supported, first-class feature for every other delimiter (key=, key:, key->, key|| all read back as {'key': ''}), so whitespace delimiters should behave the same.

Bug class

Any delimiter whose string ends in whitespace combined with an empty (or all-whitespace) value: ' ', '\t', ' ', 'x ', '= ' all raise; delimiters without trailing whitespace ('->', ' x') work.

Why it's not caught

The gh-156353 tests (test_space_delimiter, test_any_delimiter) only use non-empty values, so this edge is unpinned.

Fix

Match the option regex against a form that preserves trailing whitespace (the delimiter). optval is already stripped after the match, so ordinary values keep no trailing whitespace and the other uses of line.clean are unaffected. I have a small patch + tests and will open a PR referencing this issue.

Found with AI assistance; I've reproduced and verified the behaviour and fix on a locally built interpreter and understand them.

Linked PRs

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    stdlibStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions