BUG: Groupby-aggregate on a boolean column returns a different datatype with pyarrow than with numpy

[brian-recurve]

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

#Create a dataframe with a categorical column with two categories and a (numpy) boolean column that is randomly True or False
df = pd.DataFrame.from_dict({'category':['A']*10+['B']*10, 
                             'bool_numpy': np.random.rand(20)>0.5})

#Now make another column that is a copy of the numpy boolean column, but converted to pyarrow
df['bool_arrow'] = df['bool_numpy'].astype('bool[pyarrow]')

print(df.head())
#   category  bool_numpy bool_arrow
# 0        A        True       True
# 1        A        True       True
# 2        A        True       True
# 3        A        True       True
# 4        A       False      False

#Now do a gruopby and aggregate to compute the fraction of True values in each column:
true_fracs = df.groupby('category').agg(lambda x: x.sum()/x.count())

print(true_fracs)

#          bool_numpy bool_arrow
# category                       
# A                0.7       True
# B                0.6       True

#I expect both columns above to have identical floating-point values, not boolean.

Issue Description

Doing a groupby and aggregation on a bool[pyarrow] column returns a different datatype than the same operation on a numpy bool column. In particular, it seems to always return another bool[pyarrow] regardless of the aggregation performed.

Expected Behavior

I would expect the same datatype and results to be returned regardless of the backend chosen. Specifically, I would expect the result for category 'A' to be the same as the result of the following calculation, which is the same regardless of backend:

print(df.query("category=='A'")[['bool_numpy','bool_arrow']].sum()/df[['bool_numpy','bool_arrow']].count())
# bool_numpy    0.7
# bool_arrow    0.7
# dtype: float64

OR, if this is the intended behavior, I would expect this change to be prominently displayed in the groupby documentation.

Installed Versions

INSTALLED VERSIONS ------------------ commit : 37ea63d python : 3.8.12.final.0 python-bits : 64 OS : Linux OS-release : 5.15.0-1032-gcp Version : #40~20.04.1-Ubuntu SMP Tue Apr 11 02:49:52 UTC 2023 machine : x86_64 processor : byteorder : little LC_ALL : None LANG : C.UTF-8 LOCALE : en_US.UTF-8

pandas : 2.0.1
numpy : 1.23.5
pytz : 2022.7.1
dateutil : 2.8.2
setuptools : 57.5.0
pip : 23.0.1
Cython : 0.29.33
pytest : None
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : 3.1.2
IPython : 8.10.0
pandas_datareader: None
bs4 : 4.11.2
bottleneck : None
brotli : None
fastparquet : None
fsspec : None
gcsfs : None
matplotlib : 3.7.0
numba : 0.56.4
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : 11.0.0
pyreadstat : None
pyxlsb : None
s3fs : None
scipy : 1.10.1
snappy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : 2023.1.0
xlrd : None
zstandard : None
tzdata : 2023.3
qtpy : 2.3.0
pyqt5 : None

[rhshadrach]

Thanks for the report. Confirmed on main, further investigations and PRs to fix are welcome!

[brian-recurve]

Thanks for the quick response. I'm not familiar enough with the pandas code base (and in particular with whatever's going on with Arrow) to pursue this further, but it does seem like it has potential to surprise a fair number of users. This kind of aggregation is not uncommon.

[parthi-siva]

take

[mroeschke]

So this ends up here

https://github.com/pandas-dev/pandas/blob/a90fbc867ca9aeb66cc988f0afa2e0683364af6d/pandas/core/groupby/ops.py#L841-L844C1

we hit the preserve_dtype path which is correct, but this is tricky because we want to preserve the ArrowDtype and not necessarily the bool subtype of the result

[parthi-siva]

@mroeschke not sure how to fix this.. so unassigned myself.. Sorry for the inconvenience...

[WillAyd]

This is another good issue to track for PDEP-13 #58455

[rhshadrach]

@WillAyd - Would I be right to assume that applies to any issue tagged with pyarrow dtype retention?

[WillAyd]

Yea I think many of that tag and the Dtype Conversions issues would be clarified with that