Summary

repr() on a complex number whose real or imaginary part is an integer-valued float with |x| >= 1e16 emitted the full decimal expansion instead of scientific notation. CPython uses scientific on the same input.

# Before
>>> repr(1e100 + 1e100j)
'(1000000000000000015902891109759918046836080856394528138978132755774...<100 zeros>+1000000000000000015902891109759918046836080856394528138978132755774...<100 zeros>j)'

# CPython / After
>>> repr(1e100 + 1e100j)
'(1e+100+1e+100j)'

Root cause

crates/literal/src/complex.rs::to_string bifurcated each component by .fract() == 0.0:

let mut im_part = if im.fract() == 0.0 {
    im.to_string()          // Rust's default Display — never scientific
} else {
    float::to_string(im)    // Python-style: scientific for |x| < 1e-4 or |x| >= 1e16
};

Integer-valued f64 values — including 1e16, 1e17, 1e100 which are all exactly representable as integers — took the im.to_string() branch and rendered as full decimal expansion. Non-integer magnitudes took float::to_string and rendered correctly. The bifurcation didn't capture CPython's actual rule ("scientific iff |x| < 1e-4 or |x| >= 1e16"); it happened to be correct only when the two conditions coincidentally aligned.

Fix

Replace the two-branch logic with one helper that implements CPython's actual PyOS_double_to_string(format='r') rule:

fn component_to_string(value: f64) -> String {
    let lit = alloc::format!(\"{value:e}\");
    if let Some(position) = lit.find('e') {
        let significand = &lit[..position];
        let exponent = lit[position + 1..].parse::<i32>().unwrap();
        if exponent < 16 && exponent > -5 {
            value.to_string()                       // normal range
        } else {
            alloc::format!(\"{significand}e{exponent:+#03}\")  // scientific
        }
    } else {
        // nan / inf / -inf
        let mut s = value.to_string();
        s.make_ascii_lowercase();
        s
    }
}

The threshold matches float::to_string; the only behavioral difference is that complex components render 1.0 as \"1\" rather than \"1.0\" — matching CPython's (1+2j) convention rather than (1.0+2.0j).

Verification

Byte-identical CPython parity

Test suites

$ cargo run -- -m test test_complex
Ran 37 tests — all pass

$ cargo run -- -m test test_float test_long
Ran 101 tests (9 skipped) — all pass

$ cargo run -- -m unittest test.test_complex.ComplexTest.test_repr_str \\
      test.test_complex.ComplexTest.test_negative_zero_repr_str \\
      test.test_complex.ComplexTest.test_repr_roundtrip
Ran 3 tests in 0.004s — OK

ast unparse

The other caller of literal::complex::to_string is codegen::unparse.rs, which generates Python source from an AST. Round-trip of source containing complex literals:

$ rustpython -c 'import ast; print(ast.unparse(ast.parse(\"x = 1e100 + 1e-100j; y = 1e17 + 1j\")))'
x = 1e+100 + 1e-100j
y = 1e+17 + 1j
$ python3 -c 'import ast; print(ast.unparse(ast.parse(\"x = 1e100 + 1e-100j; y = 1e17 + 1j\")))'
x = 1e+100 + 1e-100j
y = 1e+17 + 1j

Regression snippet

extra_tests/snippets/builtin_complex.py now pins expected output at the threshold boundaries, at extremes (1e100, -1e100), with mixed magnitudes, and at the integer-vs-float rendering boundary (1+2j, 1.0+2.0j → both (1+2j)).

Scope

• In: crates/literal/src/complex.rs::to_string (the single function that renders complex repr/str/AST constants). Both callers (PyComplex::Representable and codegen::unparse) receive the fix transitively.
• Out: crates/common/src/format.rs::format_complex — this handles format-spec types ('{:.5e}'.format(c)) and is an independent code path. Its current output already matches CPython byte-identically across boundary precisions (verified in a separate audit). Not touched here.

Related

• The pre-existing TODO comment at the top of PyComplex::repr_str noted the intent to consolidate complex formatting; keeping the helper in rustpython_literal::complex matches where existing callers already look for it.

Summary by CodeRabbit

• Bug Fixes

  • Refined complex-number string formatting to match CPython rules: use scientific notation at very large/small magnitudes, omit trailing .0 for integer-valued components, and normalize NaN/Infinity rendering and signs.

• Tests

  • Added tests covering boundary transitions and comprehensive edge cases for complex number repr formatting.