Consistent validation with complex number to float type coercion

[ambroseling]

Change Summary

When validating floats in non-strict mode, this PR adds support for properly handling complex to float coercion by
by extracting their real component, this behavior is prohibited in strict mode and returns ValidationError. Appropriate unit tests are added to test_float and test_float_strict .

Related issue number

Fixes pydantic/pydantic#10430

Checklist

• Unit tests for the changes exist
• Documentation reflects the changes where applicable
• Pydantic tests pass with this pydantic-core (except for expected changes)
• My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

Selected Reviewer: @davidhewitt

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.63%. Comparing base (ab503cb) to head (8e5b5ff).
Report is 251 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1574      +/-   ##
==========================================
- Coverage   90.21%   89.63%   -0.59%     
==========================================
  Files         106      112       +6     
  Lines       16339    17898    +1559     
  Branches       36       40       +4     
==========================================
+ Hits        14740    16042    +1302     
- Misses       1592     1836     +244     
- Partials        7       20      +13     

Files with missing lines	Coverage Δ
src/input/input_python.rs	98.08% <100.00%> (+0.87%)	⬆️

... and 55 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4c02cbd...8e5b5ff. Read the comment docs.

[codspeed-hq]

CodSpeed Performance Report

Merging #1574 will not alter performance

_{Comparing ambroseling:main (8e5b5ff) with main (4c02cbd)}

Summary

✅ 155 untouched benchmarks

[ambroseling]

Hi @davidhewitt @sydney-runkle

The CI is failing due to a pyright version mismatch (trying to install v1.1.389). I've verified that this version exists in the npm registry but for some reason CI was unable to fetch it. This seems to be an infrastructure issue rather than a problem with my changes.

Would it be possible to get some guidance on this or have the CI re-run? And it would be great if my changes can be reviewed.

Thank you for your time!

[changhc]

Perhaps we should raise a warning here. In numpy's case, they do raise a custom ComplexWarning for discarding the imaginary part. At least we should document whatever coercion is implemented here because there can be a few possibilities for complex -> float:

• no coercion is allowed: consistent with the default python behaviour, e.g. float(complex(1, 2)) gives an error, even when the imaginary part is 0
• coercion is allowed only when the imaginary part is 0: this is what I would actually expect when coercions can actually take place
• coercion is allowed for all complex numbers, done by simply dropping the imaginary part: this seems to be a numpy-only behaviour and I'm not sure if non-numpy users would expect this

...if we really want to implement this coercion. Please take a look at my comment. pydantic/pydantic#10430 (comment)

[davidhewitt]

I am somewhat open to lax mode allowing complex -> float if the imaginary component is zero, similarly we allow datetime -> date if the datetime is at midnight.

I think we should never drop a nonzero imaginary part.