Trimming str before parsing to int and float

[hungtsetse]

Change Summary

Add trim() before parsing str to both int and float.
trim() is called before length check since Python behave similarly as below. Thought to match the behavior.

long_str = ' ' + '1'*4300 + ' '
assert len(long_str) == 4302
int(long_str) # valid, no errors

invalid_str = '1'*4301
int(invalid_str) # ValueError raised

Decimal isn't included since python does handle the same situation already(Python behavior).

assert Decimal(' 123 ') == Decimal('123')

It's my first contribution, please let me know if there are any I've missed or I should follow.

Related issue number

pydantic/pydantic#8419

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: @dmontagu

[codecov]

Codecov Report

Merging #1203 (6d65143) into main (1fb3343) will increase coverage by 90.24%.
Report is 14 commits behind head on main.
The diff coverage is 100.00%.

Additional details and impacted files

@@            Coverage Diff            @@
##           main    #1203       +/-   ##
=========================================
+ Coverage      0   90.24%   +90.24%     
=========================================
  Files         0      106      +106     
  Lines         0    16355    +16355     
  Branches      0       36       +36     
=========================================
+ Hits          0    14760    +14760     
- Misses        0     1588     +1588     
- Partials      0        7        +7     

Files	Coverage Δ
src/input/shared.rs	97.19% <100.00%> (ø)

... and 105 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 47aff70...6d65143. Read the comment docs.

[codspeed-hq]

CodSpeed Performance Report

Merging #1203 will degrade performances by 17.09%

_{Comparing hungtsetse:trim-str (6d65143) with main (47aff70)}

Summary

❌ 2 regressions
✅ 146 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	main	hungtsetse:trim-str	Change
❌	test_core_future	47.7 µs	55.3 µs	-13.67%
❌	test_small_class_core_dict	31.9 µs	38.5 µs	-17.09%

[hungtsetse]

please review

An additional trim downgrades performance, wonder if this trade off is acceptable.

[davidhewitt]

Thanks, looks good to me!

The performance concerns here reported are spurious and should be resolved after #1085. I think that the extra .trim() call here will be very cheap, as it's just adjusting bounds of the memory it's reading.