BUG: `metadata` on `np.ndarray` of `np.dtype("O")` dtype lost when roundtripped through `pandas.Series`

[ilan-gold]

Pandas version checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• I have confirmed this bug exists on the main branch of pandas.

Reproducible Example

import pandas as pd, numpy as np

arr = np.array(["a"], dtype=np.dtype("O", metadata={"foo":"bar"}))
assert pd.Series(arr).to_numpy().dtype.metadata is not None

Issue Description

The above does not have an assertion error under pandas<3 (i.e., 2.3.1) but does as of the displayed versions. I apologize if I'm not supposed to report this - I see the "I have confirmed this bug exists on the latest version of pandas." box but of course, it doesn't appear to happen on 2.3.1. This came up in pydata/xarray#10564

It occurs to me now that 3.0.0 may not be what is on main but that is the reported version so I'm not sure if this is a 3.0.0 problem or a main problem but here is how I work around it:

https://github.com/pydata/xarray/pull/10564/files#diff-43c76e9be8425b5b6897dcecab4b240c32580447455c0c8c0b9b7fd84ce8a15dR221-R228

See pydata/xarray#10553 for the origin of this issue

Expected Behavior

metadata is maintained

Installed Versions

INSTALLED VERSIONS

commit : faf3bbb
python : 3.12.3
python-bits : 64
OS : Darwin
OS-release : 24.1.0
Version : Darwin Kernel Version 24.1.0: Thu Oct 10 21:03:15 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T6000
machine : arm64
processor : arm
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 3.0.0.dev0+2259.gfaf3bbb1d7
numpy : 2.2.6
dateutil : 2.9.0.post0
pip : None
Cython : None
sphinx : 8.2.3
IPython : 9.4.0
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : 4.13.4
bottleneck : 1.5.0
fastparquet : None
fsspec : 2025.7.0
html5lib : None
hypothesis : 6.136.2
gcsfs : None
jinja2 : 3.1.6
lxml.etree : 6.0.0
matplotlib : 3.10.3
numba : 0.61.2
numexpr : None
odfpy : None
openpyxl : None
psycopg2 : None
pymysql : None
pyarrow : 21.0.0
pyiceberg : None
pyreadstat : None
pytest : 8.4.1
python-calamine : None
pytz : 2025.2
pyxlsb : None
s3fs : None
scipy : 1.16.0
sqlalchemy : None
tables : None
tabulate : None
xarray : 2025.7.2.dev13+gfb49a3b0.d20250724
xlrd : None
xlsxwriter : None
zstandard : None
qtpy : None
pyqt5 : None

[jorisvandenbossche]

The reason for this change is that with pandas nightly / upcoming 3.0, passing an object array of strings to pd.Series will be inferred as the new str dtype, and no longer retain the numpy object dtype:

>>> arr = np.array(["a"], dtype=np.dtype("O", metadata={"foo":"bar"}))
... pd.Series(arr)
0    a
dtype: str   # <-- no longer object dtype

If you do not want this default inference, you can specify the dtype to the Series constructor being object dtype, and in that case it seems to preserve the object dtype metadata:

>>> arr = np.array(["a"], dtype=np.dtype("O", metadata={"foo":"bar"}))
... pd.Series(arr, dtype=object).to_numpy().dtype.metadata
mappingproxy({'foo': 'bar'})

[ilan-gold]

I would be ok closing this issue then. I don't really see how we could use the fix in our use-case without somehow checking the underlying type of the object array as strings, so I'd be ok closing this issue. If you have a good way to check that would be great. It seems xarray relies on the object casting to other types as well (at least it seems so because I tried your fix and it broke other conversions in https://github.com/pydata/xarray/pull/10564/files#diff-43c76e9be8425b5b6897dcecab4b240c32580447455c0c8c0b9b7fd84ce8a15dR219)