Summary

Eight CPython parity gaps in str formatting and construction, grouped into three themes.

Group 1 — str() constructor decode mode

CPython's unicode_new_impl (Objects/unicodeobject.c) enters decode mode when encoding OR errors is provided, with separate early-reject paths for str input and non-bytes input. RustPython only checked encoding, and the non-bytes path surfaced a generic "a bytes-like object is required" error.

>>> str(b'foo', errors='strict')
# CPython 3.14.4: 'foo'
# RustPython main: "b'foo'"  ❌

>>> str('hello', errors='strict')
# CPython 3.14.4: TypeError: decoding str is not supported
# RustPython main: TypeError: a bytes-like object is required, not 'str'  ❌

>>> str(123, errors='strict')
# CPython 3.14.4: TypeError: decoding to str: need a bytes-like object, int found
# RustPython main: TypeError: a bytes-like object is required, not 'int'  ❌

Group 2 — str.format() spec engine

CPython's format spec engine (Python/formatter_unicode.c) truncates to precision before applying width pad. RustPython applied precision after, so the pad got truncated off. Separately, '{}'.format() with insufficient args wrapped Rust's tuple-index error rather than emitting CPython's domain-specific message.

>>> '{0:3.2s}'.format('abc')
# CPython 3.14.4: 'ab '
# RustPython main: 'ab'  ❌

>>> '{}'.format()
# CPython 3.14.4: IndexError: Replacement index 0 out of range for positional args tuple
# RustPython main: IndexError: tuple index out of range  ❌

The IndexError wording change covers both auto-numbered and explicit-index paths.

Group 3 — %-format integer dispatch and wording

CPython's %-format path (Objects/unicodeobject.c::formatlong and adjacent) dispatches integer conversions through PyNumber_Index (the __index__ protocol), and uses "a real number" / "an int or a unicode character" wording. RustPython only tried __int__ for %d / %i / %u, never tried __index__ for the integer-conversion error path on %x / %o / %X / %c, and used divergent wording.

>>> class P:
...     def __index__(self): return 42

>>> '%x' % P()
# CPython 3.14.4: '2a'
# RustPython main: TypeError: %x format: an integer is required, not P  ❌

>>> '%d' % P()
# CPython 3.14.4: '42'
# RustPython main: TypeError: %d format: a number is required, not P  ❌

>>> '%c' % 'foo'
# CPython 3.14.4: TypeError: %c requires an int or a unicode character, not str
# RustPython main: TypeError: %c requires int or char  ❌

%d / %i / %u now prefer __index__ over __int__ (matching CPython), and the "a number" wording becomes "a real number" for the complex/float-as-decimal mismatch. Applied to both bytes and str %-format paths.

Verification (CPython 3.14.4)

cargo run --release -- -m test test_str test_bytes test_format test_codecs test_io test_unicode_identifiers — 1,429 tests pass, 0 regressions. All 188 extra_tests/snippets/*.py pass under the CI feature set. cargo test rustpython-common cformat — 11 unit tests pass (including non-ASCII).

Tests unmasked

• Lib/test/test_str.py::test_constructor_keyword_args
• Lib/test/test_str.py::test_constructor_defaults
• Lib/test/test_descr.py::ClassPropertiesAndMethods.test_keywords — basic-type constructor parity aggregator; str(object=500) and str(object=b'abc', errors='strict') paths now pass.

Out of scope (markers retained, with updated reasons)

• test_format — '{0:08s}'.format('result') treats 0 as fill+left-align in CPython but as numeric zero-pad in RustPython's spec parser. Separate format-spec parser concern.
• test_formatting — %c error message expects fully-qualified module.qualname; RustPython returns the bare class name. Broader tp_name qualification concern.