ENH: Return type of pandas.DataFrame.dropna is incorrectly None

[rbpatt2019]

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

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

• (optional) I have confirmed this bug exists on the master branch of pandas.

---

Code Sample, a copy-pastable example

import pandas as pd
import numpy as np

example = pd.DataFrame({'a': [1, 2, 3], 'b': [4, np.nan, 6]})
example.dropna()

Problem description

Currently, the return type of pandas.DataFrame.dropna is missing. The documentation correctly states that the return type should be Optional[DataFrame], but the function definition lacks a return type, so type checkers (in my case pyright) incorrectly throw the type as None.

The issue occurs in the source code here:

pandas/pandas/core/frame.py

Line 5041 in 3e89b4c

def dropna(self, axis=0, how="any", thresh=None, subset=None, inplace=False):

It should be typed as seen in pandas.DataFrame.drop_duplicates, seen below:

pandas/pandas/core/frame.py

Lines 5183 to 5189 in 3e89b4c

	def drop_duplicates(
	self,
	subset: Optional[Union[Hashable, Sequence[Hashable]]] = None,
	keep: Union[str, bool] = "first",
	inplace: bool = False,
	ignore_index: bool = False,
	) -> Optional[DataFrame]:

More broadly, it seems that the dropna function is missing typing for its arguments as well.

Expected Output

The return type of pandas.DataFrame.dropna should be Optional[DataFrame]

I don't think this should be too hard to fix. I'll work in it tonight and submit a PR in the next day or two.

Output of pd.show_versions()

INSTALLED VERSIONS

commit : 3e89b4c
python : 3.9.1.final.0
python-bits : 64
OS : Linux
OS-release : 5.8.0-33-generic
Version : #36-Ubuntu SMP Wed Dec 9 09:14:40 UTC 2020
machine : x86_64
processor : x86_64
byteorder : little
LC_ALL : None
LANG : en_GB.UTF-8
LOCALE : en_GB.UTF-8

pandas : 1.2.0
numpy : 1.19.4
pytz : 2020.5
dateutil : 2.8.1
pip : 20.2.2
setuptools : 51.0.0
Cython : None
pytest : 6.2.1
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : None
IPython : 7.19.0
pandas_datareader: None
bs4 : None
bottleneck : None
fsspec : None
fastparquet : None
gcsfs : None
matplotlib : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyxlsb : None
s3fs : None
scipy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
xlwt : None
numba : None

[mzeitlin11]

Hi @rbpatt2019, thanks for the report! Typing PR's are certainly welcome - it's not that dropna is missing typing accidentally, it just hasn't been typed yet (same for many places in the codebase).

[simonjayhawkins]

Thanks @rbpatt2019 for the report. We can close this as we have mypy strictness flags and reports (an also now pyright #39813) to monitor type completeness rather than having open issues on the tracker.