BUG: Regression in interaction between numpy.ma and pandas with 1.24.0

[mwaskom]

Describe the issue:

Hello, this just popped up in my tests with the 1.24.0 release:

Reproduce the code example:

import numpy as np, pandas as pd
np.ma.masked_invalid(pd.Series([1., 2.]))

Error message:

---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Cell In [35], line 2
      1 import numpy as np, pandas as pd
----> 2 np.ma.masked_invalid(pd.Series([1., 2.]))

File ~/miniconda/envs/py310/lib/python3.10/site-packages/numpy/ma/core.py:2360, in masked_invalid(a, copy)
   2332 def masked_invalid(a, copy=True):
   2333     """
   2334     Mask an array where invalid values occur (NaNs or infs).
   2335 
   (...)
   2357 
   2358     """
-> 2360     return masked_where(~(np.isfinite(getdata(a))), a, copy=copy)

TypeError: ufunc 'isfinite' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''

NumPy/Python version information:

1.24.0 3.10.6 | packaged by conda-forge | (main, Aug 22 2022, 20:38:29) [Clang 13.0.1 ]

Pandas is 1.5.2

Context for the issue:

The issue seems to be with getdata, which is pulling out the index block manager rather than the values:

np.ma.getdata(pd.Series([1., 2.]))

SingleBlockManager
Items: RangeIndex(start=0, stop=2, step=1)
NumericBlock: 2 dtype: float64

Reporting to numpy rather than pandas as the error emerged with the numpy 1.24.0 update; perhaps it's an issue on the pandas side though.

[seberg]

This is also related to gh-22720, although a different angle, since np.ma.getdata() didn't change, I think. Although, I guess there is some chance that pandas introduced series._data which causes getdata to misfire.

It seems strange that getdata relies on _data without type-checking first, but I do wonder if reverting is the easier solution for 1.24.x...

EDIT: xref gh-22046 which was the PR introducing the changes.

[seberg]

Oh, the PR removed an a = np.array(a, copy=copy, subok=True) call, which I think we can just add back (it is called later anyway, and was there previously before getting the data), I wonder if that also might modify the behavior with respec tto gh-22720.

[mwaskom]

I expect that marking 1.24.0 as non-compatible is the best short-term solution? (I'm not calling np.ma directly).