BUG: assert_series_equal(..., check_exact=True, check_dtype=False) may still raise if dtypes don't match

[MarcoGorelli]

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

left = Series([10], dtype='Int64')
right = Series([10], dtype='int64')
pd.testing.assert_series_equal(left, right, check_exact=True, check_dtype=False)

Issue Description

this raises

AssertionError                            Traceback (most recent call last)
Cell In[26], line 3
      1 left = Series([10], dtype='Int64')
      2 right = Series([10], dtype='int64')
----> 3 pd.testing.assert_series_equal(left, right, check_exact=True, check_dtype=False)

    [... skipping hidden 3 frame]

File ~/tmp/.venv/lib/python3.10/site-packages/pandas/_testing/asserters.py:611, in raise_assert_detail(obj, message, left, right, diff, first_diff, index_values)
    608 if first_diff is not None:
    609     msg += f"\n{first_diff}"
--> 611 raise AssertionError(msg)

AssertionError: Series are different

Series classes are different
[left]:  IntegerArray
[right]: ndarray

Expected Behavior

this shouldn't raise

Installed Versions

INSTALLED VERSIONS

commit : 1c606d5
python : 3.10.12.final.0
python-bits : 64
OS : Linux
OS-release : 5.10.102.1-microsoft-standard-WSL2
Version : #1 SMP Wed Mar 2 00:30:59 UTC 2022
machine : x86_64
processor : x86_64
byteorder : little
LC_ALL : None
LANG : en_GB.UTF-8
LOCALE : en_GB.UTF-8

pandas : 2.2.0.dev0+694.g1c606d5f01
numpy : 1.25.1
pytz : 2023.3
dateutil : 2.8.2
setuptools : 67.6.1
pip : 23.1.2
Cython : None
pytest : 7.3.1
hypothesis : 6.82.4
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : 3.1.2
IPython : 8.16.1
pandas_datareader : None
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : 4.12.2
bottleneck : None
dataframe-api-compat : None
fastparquet : 2023.7.0
fsspec : 2023.6.0
gcsfs : None
matplotlib : 3.7.1
numba : 0.58.1
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : 12.0.1
pyreadstat : None
python-calamine : None
pyxlsb : None
s3fs : None
scipy : 1.11.0
sqlalchemy : 2.0.20
tables : None
tabulate : None
xarray : None
xlrd : None
zstandard : None
tzdata : 2023.3
qtpy : None
pyqt5 : None

[MarcoGorelli]

assert_series_equal is already a lot more complicated and buggy that I thought - I don't think we should go with any solution which increases complexity

I'd be OK with just raising if left is EA and right isn't, saying they can't be compared

[jbrockmendel]

Let’s deprecate the relevant keywords here

[jorisvandenbossche]

I just opened #56340 before finding this issue through the code comments / xfails.

I don't think that checking values (regardless of the class type, np.ndarray vs extension array) is that complicated when check_dtype=False.

[jorisvandenbossche]

And FWIW, you also see this error without manually passing check_exact=True

[MichaelTiemannOSC]

FYI, I just came back to an old PR (#54761) to add many complex number tests to the test suite. Those tests that used to pass are now failing because of this same general problem (left is EA, right is ndarray). The first failing test case can be triggered by running this case (with the changes from the PR):

pytest -k "test_loc_iloc_frame_single_dtype[complex]" pandas/tests/extension/test_numpy.py