SAY-5 opened a new pull request, #49833: URL: https://github.com/apache/arrow/pull/49833
### Rationale for this change `pyarrow.lib.Scalar` gained arithmetic dunders (`__add__`, `__sub__`, `__mul__`, `__truediv__`, `__pow__`, bitwise ops) in 24.0.0. They unconditionally call `pyarrow.compute.call_function`, which raises `TypeError` when the operand isn't a recognised pyarrow / list / tuple / ndarray type. Per the [Python data model](https://docs.python.org/3/reference/datamodel.html#object.__radd__), a forward operator must **return `NotImplemented`** (not raise) for Python to attempt the reflected operator. As a result, any user-defined class that previously handled `Scalar + my_obj` via `__radd__` / `__rmul__` stopped working between pyarrow 23 and 24. ### What changes are included in this PR? Route every binary Scalar dunder through a small `_binop_or_notimplemented` helper that catches the `TypeError` raised by `_pack_compute_args` and returns `NotImplemented` so Python can try the operand's reflected method. Unary `__neg__` / `__abs__` are unaffected because they never need a reflected fallback. ### Are these changes tested? Existing Scalar arithmetic tests continue to pass (same values, same behaviour for compute-supported operand types). A targeted unit test covering the `Scalar + user_class_with_radd` case would be a natural follow-up. ### Are there any user-facing changes? Yes, and it restores the 23.x behaviour: `Scalar.__add__(user_obj)` now returns `NotImplemented` instead of raising `TypeError`, so user-class `__radd__` handles the operation. Closes #49826. Signed-off-by: SAY-5 <[email protected]> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
