.map on category dtype does not respect defaultdict when encountering np.nan values

[WesRoach]

Using .map() to x-walk values from a series, and ensure that only expected values are present.

This scenario works to convert np.nan values to empty strings on object dtypes, but does not replace np.nan on category dtype.

import collections

import pandas as pd
import numpy as np

# "01" maps to "12", and is a valid value, while everything else should be set to ""
defdic = collections.defaultdict(lambda: "", {"01": "12"})

df = pd.DataFrame({"A": ["01", "z7", "", np.nan]})

df["A"].map(defdic)
0    12
1
2
3
Name: A, dtype: object

df["A"].astype('category').map(defdic)
0     12
1
2
3    NaN
Name: A, dtype: object

I would have expected the output to be the same for both object/category dtypes.

Output of pd.show_versions()

INSTALLED VERSIONS

commit : None
python : 3.6.3.final.0
python-bits : 64
OS : Linux
OS-release : 3.10.0-1062.4.1.el7.x86_64
machine : x86_64
processor : x86_64
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 0.25.1
numpy : 1.17.2
pytz : 2019.3
dateutil : 2.8.0
pip : 9.0.1
setuptools : 41.4.0
Cython : 0.29.13
pytest : 5.2.1
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : 2.10.3
IPython : 7.8.0
pandas_datareader: None
bs4 : None
bottleneck : None
fastparquet : 0.3.2
gcsfs : None
lxml.etree : None
matplotlib : 3.1.1
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pytables : None
s3fs : None
scipy : 1.3.1
sqlalchemy : 1.3.10
tables : None
xarray : None
xlrd : None
xlwt : None
xlsxwriter : None

[LiuSeeker]

Can I pick this issue?

[jorisvandenbossche]

This is because the mapping is applied on the categories, and those categories are only the valid values (missing values are not included in the categories, they are encoded as -1 in the integer codes underlying a categorical object).

So although it's not ideal to have this inconsistency, I am not sure it is something we should fix.
It's of course only a bandaid in your case, but you can do a .fillna("") afterwards.

[LiuSeeker]

Ok, I'll leave it this way

[WesRoach]

@LiuSeeker Thanks for the PR. The more I researched - the more I've realized how difficult a problem this is to solve.

@jorisvandenbossche Thank you for the explanation. I would love to understand your perspective a bit more if you have time: If a perfect solution could be implemented - would it be allowed? Is the issue that this shouldn't be addressed, or is the fix likely too complex, or another reason?

[simonjayhawkins]

looks like a duplicate of #22527