BUG: CategoricalDtype does not support pd.NA

[gsheni]

• 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.

---

Note: Please read this guide detailing how to provide the necessary information for us to reproduce your bug.

Code Sample, a copy-pastable example

import numpy as np
import pandas as pd

s = pd.Series([1, 2, pd.NA], dtype='category')

Out[3]:
0      1
1      2
2    NaN
dtype: category
Categories (2, int64): [1, 2]

Problem description

• pd.NA is inputted into the Series, but it is changed to np.nan.
• Since the goal of pd.NA is toprovide a “missing” indicator that can be used consistently across data types, the CategoricalDtype should support pd.NA

Expected Output

Out[3]:
0      1
1      2
2    <NA>
dtype: category
Categories (2, int64): [1, 2]

Output of pd.show_versions()

INSTALLED VERSIONS ------------------ commit : 4291973 python : 3.8.5.final.0 python-bits : 64 OS : Darwin OS-release : 19.6.0 Version : Darwin Kernel Version 19.6.0: Thu Jun 18 20:49:00 PDT 2020; root:xnu-6153.141.1~1/RELEASE_X86_64 machine : x86_64 processor : i386 byteorder : little LC_ALL : None LANG : en_US.UTF-8 LOCALE : en_US.UTF-8

pandas : 1.2.0.dev0+482.g4291973e5
numpy : 1.19.2
pytz : 2020.1
dateutil : 2.8.1
pip : 20.1.1
setuptools : 49.6.0
Cython : None
pytest : None
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : None
IPython : 7.18.1
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
pytables : None
pyxlsb : None
s3fs : None
scipy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
xlwt : None
numba : None

[arw2019]

Thanks for the report!

This is actually the expected behavior, not a bug. We currently don't plan to change this (see discussion in #35162)

[mroeschke]

Thanks for the report. As explained due to the outcome of #35162, this seems like the expected behavior so closing.