• This PR follows our AI policy

Summary

A sign, a space or an alternate form in a string format spec is accepted and then dropped:

>>> format('ab', '+')
'ab'           # CPython: ValueError: Sign not allowed in string format specifier
>>> f"{'ab':+5}"
'ab   '        # CPython: ValueError: Sign not allowed in string format specifier
>>> format('ab', '#')
'ab'           # CPython: ValueError: Alternate form (#) not allowed in string format specifier

format_string in crates/common/src/format.rs already turns down z and an explicit = alignment for strings, with the wording CPython uses. These three were never checked, so the spec parses, the flag means nothing to a string, and the caller gets plain padding where CPython refuses the spec outright.

The three checks sit next to the two that were already there. Their order is the one CPython reports in, which I read off these, under CPython 3.14:

FormatSpecError gains one variant that carries the flag name, so the three share a message built the same way as StringAlignmentFlag.

Tests

I ran the string spec shapes side by side under CPython 3.14 and this build: the four flags, fill and align pairs, width, precision, grouping, the format codes, and specs where two errors compete. Two differences are left afterwards, neither on this path. Invalid format specifier is still missing the spec and the type, which #8477 covers. And format('ab', '+,5') reports the unknown format code here while CPython reports the grouping.

• extra_tests/snippets/builtin_format.py: eight specs checked by message, next to the =8s case that was already there. It passes under CPython 3.14 too.
• two unit tests in crates/common/src/format.rs, one per flag and one for the order in the table
• cargo run --release -- -m test test_str test_format test_fstring: SUCCESS, 138, 18 and 90 tests
• cargo test --workspace --exclude rustpython_wasm --exclude rustpython-venvlauncher --exclude rustpython-capi: no failures
• cargo fmt --check, ruff format --check, ruff check --select I, and clippy with the flags CI uses: clean

test_str.test_format asserts all three, but its marker records an unrelated reason to stay an expected failure ('{0.}'.format() raises ValueError instead of IndexError), so the snippet carries the coverage instead.

AI assistance

Claude Code (claude-opus-5) helped with the comparison against CPython, the change and this description. I read the final diff and ran the checks above on Linux.

Summary by CodeRabbit

• Bug Fixes

  • Improved string formatting validation to match CPython behavior.
  • String format specifications now correctly reject unsupported sign, space, and alternate-form (#) flags.
  • Errors now report the specific unsupported formatting option and follow the expected validation precedence.

• Tests

  • Added regression coverage for rejected string format specifications and corresponding ValueError messages.