Pandas version checks

  • [X] I have checked that this issue has not already been reported.

  • [X] 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 numpy as np
import pandas as pd

df2 = pd.DataFrame({'a': [1, 2], 'b': pd.Categorical([3, np.nan])})
df2.dtypes
df2.iloc[0, :] # The series has dtype int
df2.iloc[1, :] # ValueError: cannot convert float NaN to integer

df2 = pd.DataFrame({'a': [1., 2.], 'b': pd.Categorical([3, np.nan])})
df2.dtypes
df2.iloc[0, :] # The series has dtype float
df2.iloc[1, :] # OK, because the first column is float

df2 = pd.DataFrame({'a': [1, 2], 'b': pd.Series([3, np.nan], dtype=object)})
df2.dtypes
df2.iloc[0, :] # The series has dtype object
df2.iloc[1, :] # OK, because the Series of dtype object can hold mixed element type

Issue Description

When columns are created as pd.Categorical, taking a row out sometimes encounter strange error, because a row is of type pd.Series, which has to take a fixed type for all the elements. If there is np.nan in the row, it might throw error if the earlier column is of type int. Would it make sense to make the row ALWAYS take dtype object, because it is very common to have mixed types as row ALWAYS spans different columns?

Expected Behavior

Taking a row out of a DataFrame that has a pd.Categorical column should not report inconsistent error, depending on what earlier columns are present.

Installed Versions

INSTALLED VERSIONS ------------------ commit : ba1cccd19da778f0c3a7d6a885685da16a072870 python : 3.11.5.final.0 python-bits : 64 OS : Darwin OS-release : 23.4.0 Version : Darwin Kernel Version 23.4.0: Fri Mar 15 00:10:42 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6000 machine : arm64 processor : arm byteorder : little LC_ALL : None LANG : en_US.UTF-8 LOCALE : en_US.UTF-8 pandas : 2.1.0 numpy : 1.25.2 pytz : 2023.3 dateutil : 2.8.2 setuptools : 65.5.0 pip : 24.0 Cython : None pytest : 7.4.0 hypothesis : None sphinx : None blosc : None feather : None xlsxwriter : None lxml.etree : 4.9.3 html5lib : None pymysql : None psycopg2 : None jinja2 : 3.1.2 IPython : 8.14.0 pandas_datareader : None bs4 : 4.12.2 bottleneck : None dataframe-api-compat: None fastparquet : None fsspec : None gcsfs : None matplotlib : 3.8.2 numba : None numexpr : None odfpy : None openpyxl : 3.1.2 pandas_gbq : None pyarrow : None pyreadstat : None pyxlsb : None s3fs : None scipy : 1.11.2 sqlalchemy : None tables : None tabulate : 0.9.0 xarray : None xlrd : None zstandard : None tzdata : 2023.3 qtpy : None pyqt5 : None

Comment From: rhshadrach

Thanks for the report - confirmed on main. Further investigations and PRs to fix are welcome!

Comment From: ai-naymul

Pandas version checks

  • [x] I have checked that this issue has not already been reported.
  • [x] 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

```python import numpy as np import pandas as pd

df2 = pd.DataFrame({'a': [1, 2], 'b': pd.Categorical([3, np.nan])}) df2.dtypes df2.iloc[0, :] # The series has dtype int df2.iloc[1, :] # ValueError: cannot convert float NaN to integer

df2 = pd.DataFrame({'a': [1., 2.], 'b': pd.Categorical([3, np.nan])}) df2.dtypes df2.iloc[0, :] # The series has dtype float df2.iloc[1, :] # OK, because the first column is float

df2 = pd.DataFrame({'a': [1, 2], 'b': pd.Series([3, np.nan], dtype=object)}) df2.dtypes df2.iloc[0, :] # The series has dtype object df2.iloc[1, :] # OK, because the Series of dtype object can hold mixed element type ```

Issue Description

When columns are created as pd.Categorical, taking a row out sometimes encounter strange error, because a row is of type pd.Series, which has to take a fixed type for all the elements. If there is np.nan in the row, it might throw error if the earlier column is of type int. Would it make sense to make the row ALWAYS take dtype object, because it is very common to have mixed types as row ALWAYS spans different columns?

Expected Behavior

Taking a row out of a DataFrame that has a pd.Categorical column should not report inconsistent error, depending on what earlier columns are present.

Installed Versions

Hey,

Could you please try the following code in your machine:

```import numpy as np import pandas as pd

Explicitly setting dtype to object for columns that might contain mixed types

df2 = pd.DataFrame({'a': np.array([1, 2], dtype=object), 'b': pd.Categorical([3, np.nan], categories=[3], ordered=False)}) print(df2.dtypes) print(df2.iloc[0, :])
print(df2.iloc[1, :]) ```

Comment From: cinntamani

Here is the output on my machine:

a      object
b    category
dtype: object
a    1
b    3
Name: 0, dtype: object
a      2
b    NaN
Name: 1, dtype: object

Thank you!

Comment From: samyukta-31

Hi! I would like to attempt this issue if that's alright. :)

Comment From: samyukta-31

Initial thoughts -

  1. np.nan cannot be coerced into an integer. If either the column it belongs to has float or the row it belongs to has float, it does not throw the error - rather its datatype becomes float as well

pd.DataFrame({'a': [1, 2], 'b': pd.Categorical([3.0, np.nan])}).iloc[1, :] # No error pd.DataFrame({'a': [1.0, 2.0], 'b': pd.Categorical([3, np.nan])}).iloc[1, :] # No error pd.DataFrame({'a': [1, 2], 'b': pd.Categorical([3, np.nan])}).iloc[1, :] # Error

  1. The issue repeats for None, np.datetime64('NaT') and pd.NA as well
  2. The issue repeats for pd.DataFrame({'a': [1, 2], 'b': pd.Series([3, np.nan], dtype="category")}).iloc[1, :], as well as for dtype=int (which is expected since np.nan is not an integer), but does not occur for dtpe='string', since string dtype inherently is compatible with pd.NA and therefore converts all nan values to pd.NA

Therefore the easiest way to fix this seems to be to make any column containing a Nan into an object datatype (that can accommodate heterogenous datatypes) within pandas/core/arrays/categorical.py. This however may have some performance implications, so would love to hear some thoughts on what you think the trade offs might be.

Comment From: liammaguire1

take