BUG: enum not properly handled by fillna

[PetitLepton]

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

from enum import Enum, auto
import pandas


class TestEnum(str, Enum):
    first = auto()
    second = auto()

print(pandas.Series([TestEnum.first, None, None]).fillna(TestEnum.second).tolist())

Issue Description

Hi, it seems that Enum is not correctly managed when using fillna as the code above leads to the following output.

[<TestEnum.first: '1'>, 'T', 'T']

This is also the case for version 2.0.0rc0.

Expected Behavior

The version 1.4.4 was providing the correct behaviour, namely

[<TestEnum.first: '1'>, <TestEnum.second: '2'>, <TestEnum.second: '2'>]

Installed Versions

INSTALLED VERSIONS

commit : 2e218d1
python : 3.10.9.final.0
python-bits : 64
OS : Linux
OS-release : 5.14.0-1045-oem
Version : #51-Ubuntu SMP Mon Jul 4 06:41:22 UTC 2022
machine : x86_64
processor : x86_64
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 1.5.3
numpy : 1.23.5
pytz : 2022.7.1
dateutil : 2.8.2
setuptools : 67.6.0
pip : 23.0.1
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 : 8.11.0
pandas_datareader: None
bs4 : None
bottleneck : 1.3.7
brotli : None
fastparquet : None
fsspec : None
gcsfs : None
matplotlib : None
numba : 0.56.4
numexpr : 2.8.4
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyreadstat : None
pyxlsb : None
s3fs : None
scipy : None
snappy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
xlwt : None
zstandard : None
tzdata : None

[PetitLepton]

If it helps, the issue is related to the inheritance from str as

class TestEnum(Enum):
    first = auto()
    second = auto()

works as expected.

[luke396]

confirm that the bug currently exists in the main branch.

[luke396]

This seems because of numpy. (1.24.0)

import numpy as np
from enum import Enum, auto


class TestEnum(str, Enum):
    first = auto()
    second = auto()


cond = np.array([True, False, False])
a = np.array([TestEnum.first, None, None])
b = TestEnum.second
np.where(cond, a, b) # array([<TestEnum.first: '1'>, 'T', 'T'], dtype=object)

pandas just calculate a, b, cond and return .

Edit: b = np.array(TestEnum.second) will works fine.

[PetitLepton]

It seems that converting the Series to Python string leads to the expected behavior in version 2.0.0. Indeed

from enum import Enum, auto
import pandas


class TestEnum(str, Enum):
    first = auto()
    second = auto()


print(
    pandas.Series([TestEnum.first, None, None])
    .astype("string")
    .fillna(TestEnum.second)
    .tolist()
)

reads as

[<TestEnum.first: '1'>, <TestEnum.second: '2'>, <TestEnum.second: '2'>]

[topper-123]

Yes, this is related to numpy as mentioned by @luke396. For object dtype IMO it's reasonable that pandas falls back to use numpy.where. I think it's too specific to make special code exceptions for this string enums, there may be lots of other object types that may have the same or different issues with np.where.

Generally speaking, using the object dtype can sometimes give surprising results, because pandas doesn't know what's inside object arrays. I recommend using more specific dtypes wherever possible for a better experience.

[topper-123]

So overall, I'm tending towards that this is a wontfix on pandas's side. You can try if the numpy people are interested in changing np.where.