BUG: hasnans not accounting for np.nan in FloatingArray

[galipremsagar]

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

In [14]: import pandas as pd
In [15]: import numpy as np
In [17]: import pyarrow as pa

In [18]: pa.array([np.nan, 1, 2])
Out[18]: 
<pyarrow.lib.DoubleArray object at 0x7fe90d1f31c0>
[
  nan,
  1,
  2
]
In [22]: x = pa.array([np.nan, 1, 2])

In [24]: pd.Float64Dtype().__from_arrow__(x)
Out[24]: 
<FloatingArray>
[nan, 1.0, 2.0]
Length: 3, dtype: Float64

In [25]: pd.Series(pd.Float64Dtype().__from_arrow__(x))
Out[25]: 
0    NaN
1    1.0
2    2.0
dtype: Float64

In [26]: pd.Series(pd.Float64Dtype().__from_arrow__(x)).hasnans
Out[26]: False

Issue Description

Constructing a Series with Float64Dtype dtype containing np.nan is allowed, but .hasnans returns False instead of True.

Expected Behavior

In [26]: pd.Series(pd.Float64Dtype().__from_arrow__(x)).hasnans
Out[26]: True

Installed Versions

In [27]: pd.show_versions()

INSTALLED VERSIONS

commit : 91111fd
python : 3.9.14.final.0
python-bits : 64
OS : Linux
OS-release : 4.15.0-76-generic
Version : #86-Ubuntu SMP Fri Jan 17 17:24:28 UTC 2020
machine : x86_64
processor : x86_64
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 1.5.1
numpy : 1.23.5
pytz : 2022.6
dateutil : 2.8.2
setuptools : 65.5.1
pip : 22.3.1
Cython : 0.29.32
pytest : 7.2.0
hypothesis : 6.58.0
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.6.0
pandas_datareader: None
bs4 : 4.11.1
bottleneck : None
brotli :
fastparquet : None
fsspec : 2022.11.0
gcsfs : None
matplotlib : None
numba : 0.56.3
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : 9.0.0
pyreadstat : None
pyxlsb : None
s3fs : 2022.11.0
scipy : 1.9.3
snappy :
sqlalchemy : 1.4.44
tables : None
tabulate : 0.9.0
xarray : None
xlrd : None
xlwt : None
zstandard : None
tzdata : None

[mroeschke]

This behavior might be impacted by discussion in #32265

[larsyencken]

We get the same issue on Python 3.10 and Pandas 1.5.2, where some operations can end you up with a Float64 series that doesn't appear to be expecting np.nan and just doesn't check for it in the expected ways:

In [1]: s = pd.Series([1], dtype='UInt32') / pd.Series([np.nan], dtype='float64')

In [2]: s
Out[2]:
0    NaN
dtype: Float64

In [3]: s.isnull()
Out[3]:
0    False
dtype: bool

In [4]: s.fillna(0)
Out[4]:
0    NaN
dtype: Float64

In [5]: s.hasnans
Out[5]: False

[a-reich]

@mroeschke would a PR updating FloatingArray’s
isna method to detect (or optionally detect) NaN be accepted? or is any such change blocked on a consensus for redesigning FloatingArray?

[mroeschke]

I think the discussion in #32265 should have a little more consensus as this may impact how hasnans treats NA vs nan