Right now, IntegerArary.__add__ calls np.asarray(other) for list-like other. When other is an actual list with missing values, we end up with a float ndarray.
In [2]: arr = pd.Series([1, None, 3], dtype='Int8').values
In [3]: arr + list(arr)
Out[3]: array([ 2., nan, 6.])
Compare with Non-NA values:
In [4]: arr = pd.Series([1, 2, 3], dtype='Int8').values
In [6]: arr + list(arr)
Out[6]: IntegerArray([2, 4, 6], dtype='Int8')
In general, an IntegerArray + ndarray[float] should be a floating point ndarray,
In [10]: arr + np.array([1., 2., 3.])
Out[10]: array([2., 4., 6.])
Do we special case missing values here?
Comment From: jorisvandenbossche
A possible solution would be to first try to convert the list to an IntegerArray, and only if that fails to an np.ndarray. So that would ensure that the list with integers / NaNs becomes IntegerArray, and thus the result will also be one.
But a disadvantage of that is that then something like arr + [1.0, 2.0, 3.0] will also give IntegerArray as result instead of float array (which is what numpy gives, since the list are floats). And I am not sure to limit integer_array(..) constructor to require actual ints and error on a list of round floats.
Comment From: TomAugspurger
Yeah, the round float case is unfortunate. What's the least surprising behavior here? I think that since lists are un-typed, we having different return types for
In [15]: integer_array([1, 2, 3]) + integer_array([1, None, 3])
Out[15]: IntegerArray([2, nan, 6], dtype='Int64')
In [16]: integer_array([1, 2, 3]) + [1, np.nan, 3]
Out[16]: array([ 2., nan, 6.])
is the most surprising. I'd be willing to have the round float case be swallowed up by integer array if necessary. So maybe the rule is "can we safely cast the right-hand side to an IntegerArray? If so, the return type is an IntegerArray"
Comment From: jorisvandenbossche
So maybe the rule is "can we safely cast the right-hand side to an IntegerArray?
I think that would be fine for now (although it is different from numpy), certainly given that a list has not really dtype information.
Alternatively, we could error on integer_array([1.0, 2.0]), but that would also be very annoying, because integer_array is currently useful for converting our current "integer with nan = foat" to IntegerArray
Comment From: jbrockmendel
So maybe the rule is "can we safely cast the right-hand side to an IntegerArray?
Proposal: punt. In practice we expect IntegerArray.__add__ to be called indirectly via e.g. Series.__add__, and the Series method will do any relevant casting on the list. At this level we can just raise.