BUG: static typechecking fails when assert_<object>_equal is not given <object> instances.

[johannes-mueller]

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

def divide_series_by(s: pd.Series, prm: int) -> pd.Series | None:
    try:
        result = s / prm
    except ZeroDivisionError:
        return None

    return result

s = pd.Series([1., 2., 3., 4.])

result = divide_series_by(s, 1)

# assert result is not None  # This is a workaround
pd.testing.assert_series_equal(result, s)  # mypy complains

Issue Description

Running mypy on the above code snippet results in

error: Argument 1 to "assert_series_equal" has incompatible type "Optional[Series[Any]]"; expected "Series[Any]"  [arg-type]

Expected Behavior

The mypy run should run successfully without reporting issues.

In my opinion there should be an easy possibility to assert the equality of two pandas objects completely (i.e. even the type equality) at runtime. When testing functions like in the above example, I consider it part of assert_series_equal to also assert that left is actually a Series.

Of course one could assert the type correctness in an extra assertion (like in the workaround shown above). That makes mypy happy but that would not add further value to the unit test IMHO.

An alternative might be to make assert_almost_equal public. But I have not looked into that option too much.

Installed Versions

INSTALLED VERSIONS ------------------ commit : 2e218d10984e9919f0296931d92ea851c6a6faf5 python : 3.11.0.final.0 python-bits : 64 OS : Linux OS-release : 5.4.0-144-generic Version : pandas-dev/pandas#161-Ubuntu SMP Fri Feb 3 14:49:04 UTC 2023 machine : x86_64 processor : x86_64 byteorder : little LC_ALL : None LANG : de_DE.UTF-8 LOCALE : de_DE.UTF-8

pandas : 1.5.3
numpy : 1.24.2
pytz : 2022.7.1
dateutil : 2.8.2
setuptools : 65.5.0
pip : 22.2.2
Cython : None
pytest : 7.2.2
hypothesis : None
sphinx : 5.3.0
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : 3.1.2
IPython : 8.11.0
pandas_datareader: None
bs4 : 4.11.2
bottleneck : None
brotli : None
fastparquet : None
fsspec : None
gcsfs : None
matplotlib : 3.7.1
numba : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyreadstat : None
pyxlsb : None
s3fs : None
scipy : None
snappy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
xlwt : None
zstandard : None
tzdata : None

[twoertwein]

I assume you have pandas-stubs installed. Moved to pandas-stubs.

Pandas itself has no annotation for the first argument (and is not a py.typed library) - it cannot trigger the error you are seeing.

[Dr-Irv]

The documentation for assert_series_equal() says that the two arguments should be Series. In fact, if you pass None for either argument, pandas will raise an exception.

So in this particular case, the typing stubs as well as the result shown by mypy are correct. None is an invalid argument to assert_series_equal()

[johannes-mueller]

Fair enough. From a developer point of view I would still argue that assert_*_equal should type-check-wise accept Any. When I in a unit test want to use assert_series_equal to assert that my result is a) a Series and b) equal to the other Series, it is annoying that the type checker complains that my result might not be a Series. I know that it might not be a Series. That's why I am writing the test.

Of course, on the other hand it can be said, that it is bad style to test the two things a) and b) from above in one single assertion and it is more transparent to do one assertion for each of them.

So ok, fair enough. Thanks for considering.