Preserve imaginary zero signs when adding real values to complex numbers by moreal · Pull Request #7421 · RustPython/RustPython

291-303: Generic type parameter ordering is inconsistent with function parameter ordering.

The generic type parameters are declared as CCF, RCF, CRF, but the function parameters are ordered as cc_op, cr_op, rc_op. This mismatch is confusing—RCF (second generic) corresponds to rc_op (third parameter), while CRF (third generic) corresponds to cr_op (second parameter).

🔧 Suggested fix: reorder generic type parameters
-    fn complex_real_binop<CCF, RCF, CRF, R>(
+    fn complex_real_binop<CCF, CRF, RCF, R>(
         a: &PyObject,
         b: &PyObject,
         cc_op: CCF,
         cr_op: CRF,
         rc_op: RCF,
         vm: &VirtualMachine,
     ) -> PyResult
     where
         CCF: FnOnce(Complex64, Complex64, &VirtualMachine) -> R,
-        CRF: FnOnce(Complex64, f64, &VirtualMachine) -> R,
-        RCF: FnOnce(f64, Complex64, &VirtualMachine) -> R,
+        CRF: FnOnce(Complex64, f64, &VirtualMachine) -> R,
+        RCF: FnOnce(f64, Complex64, &VirtualMachine) -> R,
         R: ToPyResult,
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@crates/vm/src/builtins/complex.rs` around lines 291 - 303, The generic type
parameter order in complex_real_binop is inconsistent with the function
parameter order; reorder the type parameters from CCF, RCF, CRF to CCF, CRF, RCF
so that CCF -> cc_op, CRF -> cr_op, and RCF -> rc_op (update the where-clause
and all uses of these type parameters in the signature accordingly).