Skip to content

literal: reject internal whitespace in complex::parse_str - #8242

Merged
youknowone merged 1 commit into
RustPython:mainfrom
youknowone:complex-parse-ws
Jul 9, 2026
Merged

literal: reject internal whitespace in complex::parse_str#8242
youknowone merged 1 commit into
RustPython:mainfrom
youknowone:complex-parse-ws

Conversation

@youknowone

@youknowone youknowone commented Jul 8, 2026

Copy link
Copy Markdown
Member

complex::parse_str splits the token on the central +/- and parses each side with float::parse_str, which tolerates surrounding whitespace on a fragment. As a result complex("1 +2j") parsed as (1+2j) instead of raising.

Whitespace is only valid around the whole string and the optional parentheses, never inside the numeric token. Reject any whitespace remaining after the parentheses are stripped, matching CPython (complex("1 +2j")ValueError).

Added unit tests: internal-whitespace rejection, surrounding/paren whitespace acceptance, and basic parsing (incl. underscores).

assisted by Claude

Summary by CodeRabbit

  • Bug Fixes

    • Improved complex number parsing to reject inputs with whitespace inside the numeric content (e.g., 1 +2j, 2 -3j), while still allowing whitespace around the full literal and around optional outer parentheses.
  • Tests

    • Added unit tests and extended parsing tests to cover accepted outer whitespace/parentheses formats and rejected internal-whitespace variants for complex string parsing.

@coderabbitai

coderabbitai Bot commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

📝 Walkthrough

Walkthrough

Modifies parse_str in the complex literal parser to reject inputs containing internal ASCII whitespace after trimming, while still permitting surrounding whitespace and optional outer parentheses. Adds unit tests and snippet tests covering rejection and acceptance cases.

Changes

Complex Literal Whitespace Validation

Layer / File(s) Summary
Whitespace rejection and tests
crates/literal/src/complex.rs, extra_tests/snippets/builtin_complex.py
parse_str now returns None if trimmed input contains internal whitespace; tests verify rejection of internal-whitespace variants and acceptance of surrounding/parentheses whitespace plus basic valid/invalid parsing cases.

Estimated code review effort: 1 (Trivial) | ~5 minutes

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately and specifically summarizes the main change: rejecting internal whitespace in complex parsing.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@youknowone
youknowone marked this pull request as ready for review July 8, 2026 16:57
// parentheses, never inside the numeric token. Reject it here so that
// `float::parse_str` (which tolerates surrounding whitespace on a part)
// does not let e.g. "1 +2j" through.
if s.contains(char::is_whitespace) {

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a test in extra_tests

parse_str split the token then parsed each part with float::parse_str,
which tolerates surrounding whitespace, so "1 +2j" parsed as (1+2j).
Reject whitespace inside the token after stripping optional parentheses.
Add unit tests and complex() snippet tests.

Assisted-by: Claude

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
extra_tests/snippets/builtin_complex.py (1)

176-178: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Consider adding a test for whitespace inside parentheses within the numeric token.

The current tests cover internal whitespace rejection without parentheses (lines 176-178) and whitespace around parentheses (line 175), but don't test the interaction: complex("(1 +2j)") where whitespace is inside parentheses and inside the numeric token. Per the PR logic, stripping parentheses yields "1 +2j" which should raise ValueError. Adding this case would directly validate the parentheses-stripping + whitespace-rejection interaction.

💡 Suggested additional test case
 assert_raises(ValueError, lambda: complex("1 + 2j"))
+assert_raises(ValueError, lambda: complex("(1 +2j)"))
+assert_raises(ValueError, lambda: complex("(1+ 2j)"))
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@extra_tests/snippets/builtin_complex.py` around lines 176 - 178, Add a
regression test in builtin_complex.py for complex("(1 +2j)") to cover whitespace
inside parentheses and inside the numeric token. Extend the existing
assert_raises(ValueError, ...) cases near the complex string parsing tests so
this interaction is explicitly validated after parentheses stripping. Keep the
new case alongside the other complex(...) whitespace rejection checks to make
the intended behavior clear.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@extra_tests/snippets/builtin_complex.py`:
- Around line 176-178: Add a regression test in builtin_complex.py for
complex("(1 +2j)") to cover whitespace inside parentheses and inside the numeric
token. Extend the existing assert_raises(ValueError, ...) cases near the complex
string parsing tests so this interaction is explicitly validated after
parentheses stripping. Keep the new case alongside the other complex(...)
whitespace rejection checks to make the intended behavior clear.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Pro

Run ID: bf15f579-9fc3-41e4-a208-6e778ea21f82

📥 Commits

Reviewing files that changed from the base of the PR and between bc209d9 and 49edd70.

📒 Files selected for processing (2)
  • crates/literal/src/complex.rs
  • extra_tests/snippets/builtin_complex.py
🚧 Files skipped from review as they are similar to previous changes (1)
  • crates/literal/src/complex.rs

@youknowone
youknowone merged commit 150990e into RustPython:main Jul 9, 2026
26 checks passed
@youknowone
youknowone deleted the complex-parse-ws branch July 9, 2026 11:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant