BUG: assert_frame_equal changes behavior in 3.0 for nested arrays without documentation

[gaogaotiantian]

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 numpy as np
import pandas as pd
from pandas.testing import assert_frame_equal

df1 = pd.DataFrame({"a": [[1]]})
df2 = pd.DataFrame({"a": [np.array([1])]})

assert_frame_equal(df1, df2, check_exact=True)

Issue Description

This code above raises in 3.0.0 and passes in 2.3.x. I can understand the behavior but there's no docs in what's new of 3.0.0 about this. Is this considered a bug fix? Is the current behavior expected?

Expected Behavior

I don't know. I can live with either but it's nice if it's stable and documented.

Installed Versions

Details

INSTALLED VERSIONS

commit : 9c8bc3e
python : 3.12.12
python-bits : 64
OS : Darwin
OS-release : 25.2.0
Version : Darwin Kernel Version 25.2.0: Tue Nov 18 21:09:56 PST 2025; root:xnu-12377.61.12~1/RELEASE_ARM64_T6041
machine : arm64
processor : arm
byteorder : little
LC_ALL : None
LANG : C.UTF-8
LOCALE : C.UTF-8

pandas : 2.3.3
numpy : 2.3.4
pytz : 2025.2
dateutil : 2.9.0.post0
pip : 25.0.1
Cython : None
sphinx : 4.5.0
IPython : 9.6.0
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : 4.14.2
blosc : None
bottleneck : None
dataframe-api-compat : None
fastparquet : None
fsspec : 2025.9.0
html5lib : None
hypothesis : None
gcsfs : None
jinja2 : 3.1.6
lxml.etree : 6.0.2
matplotlib : 3.10.7
numba : None
numexpr : None
odfpy : None
openpyxl : 3.1.5
pandas_gbq : None
psycopg2 : None
pymysql : None
pyarrow : 21.0.0
pyreadstat : None
pytest : 8.4.2
python-calamine : None
pyxlsb : None
s3fs : None
scipy : 1.16.3
sqlalchemy : 2.0.44
tables : None
tabulate : None
xarray : None
xlrd : None
xlsxwriter : None
zstandard : 0.25.0
tzdata : 2025.2
qtpy : None
pyqt5 : None

vs

Details

INSTALLED VERSIONS

commit : 366ccdf
python : 3.12.12
python-bits : 64
OS : Darwin
OS-release : 25.2.0
Version : Darwin Kernel Version 25.2.0: Tue Nov 18 21:09:56 PST 2025; root:xnu-12377.61.12~1/RELEASE_ARM64_T6041
machine : arm64
processor : arm
byteorder : little
LC_ALL : None
LANG : C.UTF-8
LOCALE : C.UTF-8

pandas : 3.0.0
numpy : 2.3.4
dateutil : 2.9.0.post0
pip : 25.0.1
Cython : None
sphinx : 4.5.0
IPython : 9.6.0
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : 4.14.2
bottleneck : None
fastparquet : None
fsspec : 2025.9.0
html5lib : None
hypothesis : None
gcsfs : None
jinja2 : 3.1.6
lxml.etree : 6.0.2
matplotlib : 3.10.7
numba : None
numexpr : None
odfpy : None
openpyxl : 3.1.5
psycopg2 : None
pymysql : None
pyarrow : 21.0.0
pyiceberg : None
pyreadstat : None
pytest : 8.4.2
python-calamine : None
pytz : 2025.2
pyxlsb : None
s3fs : None
scipy : 1.16.3
sqlalchemy : 2.0.44
tables : None
tabulate : None
xarray : None
xlrd : None
xlsxwriter : None
zstandard : 0.25.0
qtpy : None
pyqt5 : None

[kjmin622]

Thanks for reporting this issue.

I traced this to PR #59778, which added a check in array_equivalent_object to return False when one side is a numpy array and the other is not, specifically to avoid numpy deprecation warnings when comparing nested arrays containing empty arrays/lists.

            elif PyArray_Check(x) or PyArray_Check(y):
                return False

However, there's an ambiguity here. The original intent was to handle only the empty array/list case, which is why it wasn't documented in the release notes. But the current implementation returns False for all cases where the types differ (e.g., list vs numpy.ndarray), not just empty ones.

Interestingly, comparing a list with a pandas array (as opposed to a numpy array) works correctly. This inconsistency suggests this is unintended behavior.

I'd like to submit a fix for this. Maintainers, please let me know if this assessment is correct and if a PR would be welcome.