◐ Shell
clean mode source ↗

Remove wrong Deref by youknowone · Pull Request #6620 · RustPython/RustPython

30-46: LGTM! Macro correctly uses explicit conversion.

The call_math_func! macro now explicitly converts the argument via into_float() before calling the math function, making the conversion path clear while preserving the original behavior and error handling.


56-114: LGTM! Consistent explicit conversions in predicate and comparison functions.

The isfinite, isinf, isnan, and isclose functions now use explicit into_float() conversions. The isclose function correctly uses map_or to handle optional tolerance parameters with inline conversion, maintaining the original logic while improving clarity.


117-243: LGTM! Power, logarithmic, and root functions correctly updated.

All functions (copysign, log, log1p, pow, sqrt, isqrt) now use explicit conversions:

  • into_float() for floating-point arguments
  • Into::into where type inference is sufficient (line 139)
  • into_int_ref() for integer arguments (line 235)

The mix of into_float() and Into::into is intentional and appropriate for type inference contexts.


245-479: LGTM! Trigonometric and hyperbolic functions correctly refactored.

All trigonometric (acos, asin, atan, atan2, cos, sin, tan, degrees, radians) and hyperbolic (acosh, asinh, atanh, cosh, sinh, tanh) functions consistently use into_float() for explicit conversion. The mixed use of into_float() and into() (e.g., line 272: y.into_float().atan2(x.into())) is appropriate for type inference.


482-500: LGTM! Special functions use trait-based conversion.

The special functions (erf, erfc, gamma, lgamma) use Into::into for conversion to the pymath library types, which is appropriate for generic trait-based conversions.


547-555: LGTM! frexp uses type inference for conversion.

The function correctly uses Into trait conversion with explicit type annotation (let value: f64 = x.into();), which is clear and allows type inference.


639-667: LGTM! Integer operations correctly use reference access.

The helper function math_perf_arb_len_int_op and its callers (gcd, lcm) correctly use as_ref() to access already-converted ArgIndex values. This is distinct from the initial conversion pattern using into_int_ref() seen elsewhere, and is appropriate for this context where values are stored in a vector and accessed multiple times.


671-770: LGTM! Aggregate and sequence functions correctly updated.

Functions cbrt, fsum correctly use explicit conversions. The fsum function on line 682 converts each iterated object via obj?.into_float(), maintaining the accumulation logic while making conversions explicit.


792-862: LGTM! Combinatorial functions correctly use integer conversions.

The perm and comb functions correctly use into_int_ref() for their integer arguments (lines 797, 802, 826, 828), ensuring proper conversion to BigInt references for combinatorial calculations.


865-906: LGTM! modf and nextafter correctly refactored.

The modf function uses into_float() for conversion, and nextafter correctly uses:

  • into_int_ref() for the optional steps parameter (line 892)
  • Into::into for the x and y float parameters (lines 895-896)

This mixed approach is appropriate and maintains the original behavior.


909-1051: LGTM! Remaining functions correctly use explicit conversions.

The ulp, fmod, remainder, and fma functions all correctly use explicit into_float() conversions. The fma function properly converts all three arguments (lines 1033-1036) before calling mul_add, maintaining the fused multiply-add semantics with explicit conversion paths.