pandas.arrays.StringArray is now whitelisted

[ilan-gold]

What happened?

Was this the intention with NumpyExtensionArray whitelisting? I am not sure this is a bug since numpy technically supports na-ed strings via the object dtype but just checking.

What did you expect to happen?

I am not sure this was the intention, honestly. It seemed like we only wanted numeric types but maybe I'm misremembering. That being said, this does highlight the downsides of these sorts of behavior changes.

Minimal Complete Verifiable Example

import numpy as np, pandas as pd

pd.Series(pd.array(["a", np.nan], dtype=pd.StringDtype())).to_xarray()



<xarray.DataArray (index: 2)> Size: 16B
array(['a', <NA>], dtype=object)
Coordinates:
  * index    (index) int64 16B 0 1

MVCE confirmation

• Minimal example — the example is as focused as reasonably possible to demonstrate the underlying issue in xarray.
• Complete example — the example is self-contained, including all data and the text of any traceback.
• Verifiable example — the example copy & pastes into an IPython prompt or Binder notebook, returning the result.
• New issue — a search of GitHub Issues suggests this is not a duplicate.
• Recent environment — the issue occurs with the latest version of xarray and its dependencies.

Relevant log output

Anything else we need to know?

No response

Environment

INSTALLED VERSIONS

commit: None
python: 3.13.0 (main, Oct 7 2024, 05:02:14) [Clang 16.0.0 (clang-1600.0.26.3)]
python-bits: 64
OS: Darwin
OS-release: 24.1.0
machine: arm64
processor: arm
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8
LOCALE: ('en_US', 'UTF-8')
libhdf5: 1.14.6
libnetcdf: None

xarray: 2025.6.1
pandas: 2.3.0
numpy: 2.2.6
scipy: 1.15.3
netCDF4: None
pydap: None
h5netcdf: None
h5py: 3.14.0
zarr: 3.0.9.dev18+g402777a5
cftime: None
nc_time_axis: None
iris: None
bottleneck: None
dask: 2025.1.0
distributed: 2025.1.0
matplotlib: 3.10.3
cartopy: None
seaborn: 0.13.2
numbagg: None
fsspec: 2025.5.1
cupy: None
pint: None
sparse: None
flox: None
numpy_groupies: 0.11.3
setuptools: 80.9.0
pip: None
conda: None
pytest: 8.3.3
mypy: None
IPython: 9.3.0
sphinx: None

[ilan-gold]

#10301 (comment) I guess that's then that's what it is.

[ilan-gold]

Ok I'm reopening this because it would be a large regression for us. I apologize for not testing this with our repository, I am going to make it so that we test against xarray main going forward.

For most people, the answer for us going forward would be to handle string types as object to be able to use nullable values but having a native nullable representation would be ideal.

I am looking into it now - I'm sure there is a way around this but it's a bit frustrating :/

Judging by the source code, they store string arrays under the hood as object types: https://github.com/pandas-dev/pandas/blob/v2.3.0/pandas/core/arrays/string_.py#L543-L1054

This makes things a bit more challenging because now we'll have to track what was a string array on-disk through to the roundtrip to pandas

[ilan-gold]

Judging by the source code, they store string arrays under the hood as object types: https://github.com/pandas-dev/pandas/blob/v2.3.0/pandas/core/arrays/string_.py#L543-L1054

Given this I think we can close this, not thrilled about this, but I'd rather just have the stability at this point.