BUG: infer_objects doesn't infer arrays with pd.NA in it correctly

[lithomas1]

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
import numpy as np
s1 = pd.Series([1.0, pd.NA, 2.0])
s1.infer_objects(copy=False)

Issue Description

The code snippet returns object dtype instead of Float64Dtype.

Expected Behavior

Float64Dtype is the resulting dtype

Installed Versions

INSTALLED VERSIONS

commit : 47d48f1
python : 3.10.12.final.0
python-bits : 64
OS : Darwin
OS-release : 22.5.0
Version : Darwin Kernel Version 22.5.0: Thu Jun 8 22:22:22 PDT 2023; root:xnu-8796.121.3~7/RELEASE_X86_64
machine : x86_64
processor : i386
byteorder : little
LC_ALL : None
LANG : None
LOCALE : None.UTF-8

pandas : 2.1.0.dev0+1383.g47d48f143e
numpy : 1.24.4
pytz : 2023.3
dateutil : 2.8.2
setuptools : 68.0.0
pip : 23.2.1
Cython : 3.0.0
pytest : 7.4.0
hypothesis : 6.82.0
sphinx : 4.5.0
blosc : None
feather : None
xlsxwriter : 3.1.2
lxml.etree : 4.9.3
html5lib : 1.1
pymysql : 1.4.6
psycopg2 : 2.9.6
jinja2 : 3.1.2
IPython : 8.14.0
pandas_datareader: None
bs4 : 4.12.2
bottleneck : 1.3.7
brotli :
fastparquet : 2023.7.0
fsspec : 2021.07.0
gcsfs : 2021.07.0
matplotlib : 3.7.2
numba : 0.57.1
numexpr : 2.8.4
odfpy : None
openpyxl : 3.1.2
pandas_gbq : None
pyarrow : 12.0.0
pyreadstat : 1.2.2
pyxlsb : 1.0.10
s3fs : 2021.07.0
scipy : 1.11.1
snappy :
sqlalchemy : 2.0.19
tables : 3.8.0
tabulate : 0.9.0
xarray : 2023.7.0
xlrd : 2.0.1
zstandard : 0.19.0
tzdata : 2023.3
qtpy : None
pyqt5 : None

[jbrockmendel]

Any reason why Float64 instead of float64[pyarrow]?

[lithomas1]

Any reason why Float64 instead of float64[pyarrow]?

No strong preference here. Anything is better than object :)

[jbrockmendel]

Anything is better than object :)

I'm with you there.

NDFrame.infer_objects() goes through lib.maybe_infer_objects, which is also used by many of our constructors. There are similar issues for constructors e.g. #33662. I think we can make a decision about the constructors once we make a decision about #32265, which I'm hopeful we'll do next week.

[attack68]

should close #54400