The non-integral rejection added in fb5cce6 only covered exact Python
floats: Runtime.PyFloat_Check compares the type pointer, so float
subclasses such as numpy.float64 and __float__-only numbers such as
numpy.float32 bypassed the guard in Converter.ToPrimitive and fell
through to PyNumber_Long/__int__, silently truncating the value (e.g.
SimpleMovingAverage(np.float64(20.5)) built a period-20 indicator).
Extend the guard to any float-like value: Python floats including
subclasses, and numbers that define __float__ but no __index__. True
integer types advertising __index__ (numpy.int64/int32) and plain ints
are unaffected, and integral-valued floats (20.0) keep converting.
Adds embed tests with float-subclass / __float__-only / __index__
fixtures and a numpy-backed python test over ConversionTest fields and
method binding.
What does this implement/fix? Explain your changes.
Passing a non-integral numpy float where a .NET integer parameter is expected silently truncates instead of raising: SimpleMovingAverage(np.float64(20.5)) builds a period-20 indicator, while plain float(20.5) is correctly rejected with a TypeError.
fb5cce6 (#128) added the non-integral rejection for Python floats, but the guard in Converter.ToPrimitive uses Runtime.PyFloat_Check, an exact type-pointer check. Two kinds of values bypass it and fall through to PyNumber_Long/__int__, which truncates:
This PR extends the guard to any float-like value:
Integral-valued floats (np.float64(20.0)) keep converting, numpy integer scalars (np.int64, np.int32, which advertise __index__) are unaffected, and plain ints take a fast early exit. If a probed __float__ call fails, the pending Python error is cleared before rejecting, so no stale error leaks.
Behavior note: non-numpy numeric types with __float__/__int__ but no __index__ (e.g. decimal.Decimal, fractions.Fraction) previously also truncated silently into integer parameters (Decimal("20.5") → 20); with this change their non-integral values are rejected the same way, while integral values keep converting exactly as before.
Does this close any currently open issues?
No open issue; found while reproducing the fleet error-surface study (Agents#305, improvement 1).
Any other comments?
Tests:
Checklist
Check all those that are applicable and complete.