[Python] Support arithmetic on arrays and scalars

[asfimport]

I was surprised to find you can't use standard arithmetic operators on PyArrow arrays and scalars. Instead, one must use the compute functions:

import pyarrow as pa

arr = pa.array([1, 2, 3])
pc.add(arr, 2)
# Doesn't work:
# arr + 2
# arr + pa.scalar(2)
# arr + arr

pc.multiply(arr, 20)
# Doesn't work:
# 20 * arr
# pa.scalar(20) * arr

Is it intentional we don't support this?

Reporter: Will Jones / @wjones127
Watchers: Rok Mihevc / @rok

_{Note: This issue was originally created as ARROW-16658. Please see the migration documentation for further details.}

[asfimport]

David Li / @lidavidm:
I don't think it's been discussed. Operators could be added just for convenience.

[asfimport]

Antoine Pitrou / @pitrou:
I think it is intentional as we don't (or didn't) want PyArrow to be used as a Numpy replacement. We could revisit that choice of course.

Note that if we go this way, the hairy topic of relational operators (\_\_eq\_\_, etc.) will quickly come up.

@jorisvandenbossche @amol-

[asfimport]

Alessandro Molina / @amol-:
I think it's reasonable to add those operators to Arrays. In the end we already provide those features, it's not that we would be implementing something new.
I think relying on operators to manipulate arrays is a spread enough pattern in Python that it's a good idea to support it.

[asfimport]

Antoine Pitrou / @pitrou:
There are other questions such as which options do we pass. We probably don't want to issue unchecked arithmetic by default, for example.

[asfimport]

Joris Van den Bossche / @jorisvandenbossche:
For the options or checked vs non checked, we indeed need to pick some default, but I think that's OK (and I would indeed also go for the checked versions).

I think if we add those, we should also change the behaviour of __eq__, although that is something that will require a long deprecation cycle.

[pitrou]

@rok @AlenkaF @thisisnic I think this would still be a useful improvement.

[rok]

Agreed. As per Joris's comment we could start with deprecating __eq__ :D

[AlenkaF]

cc @rmnskb in case you would be interested in working on this issue.

[rmnskb]

cc @rmnskb in case you would be interested in working on this issue.

Yeah, looks interesting, I would like to give it a shot, thanks!

[rmnskb]

take