BUG: Regression for grouping on Decimal values when upgrading from 1.3 to 2.0.3

[stevenlandis-rl]

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
from decimal import Decimal

frame = pandas.DataFrame(
    columns=["group_field", "value_field"],
    data=[
        [Decimal(1), Decimal(2)],
        [Decimal(1), Decimal(3)],
        [None, Decimal(4)],
        [None, Decimal(5)],
    ],
)

group_by = frame.groupby("group_field", dropna=False)
sum = group_by["value_field"].sum()
print(sum)

Issue Description

When trying to upgrade from pandas 1.3.0 to 2.0.3 I noticed that tests that grouped on a mixture of decimals and Nones were failing with the following error:

decimal.InvalidOperation: [<class 'decimal.InvalidOperation'>]

Even though I upgraded pandas, version of numpy stayed the same at 1.24.3.

Looking deeper it looks like the safe_sort function first tries to sort data using values.argsort(), but since that raises a decimal.InvalidOperation instead of a TypeError it fails. I was able to fix this by adding the new exception type to the except clause like this:

except (TypeError, decimal.InvalidOperation):

Hopefully this is an easy 1-line fix but please let me know if you have questions or concerns. Thanks!

Expected Behavior

Sum from the print statement should be the series that looks like this:

group_field
1      5
NaN    9
Name: value_field, dtype: object

Installed Versions

INSTALLED VERSIONS

commit : 0f43794
python : 3.9.13.final.0
python-bits : 64
OS : Darwin
OS-release : 22.6.0
Version : Darwin Kernel Version 22.6.0: Wed Jul 5 22:22:05 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6000
machine : arm64
processor : arm
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 2.0.3
numpy : 1.24.3
pytz : 2023.3
dateutil : 2.8.2
setuptools : 68.1.2
pip : 22.3.1
Cython : 0.29.34
pytest : 5.2.2
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : 2.9.5
jinja2 : 3.1.2
IPython : None
pandas_datareader: None
bs4 : None
bottleneck : None
brotli : None
fastparquet : None
fsspec : None
gcsfs : None
matplotlib : 3.7.0
numba : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyreadstat : None
pyxlsb : None
s3fs : None
scipy : None
snappy : None
sqlalchemy : 1.4.31
tables : None
tabulate : None
xarray : None
xlrd : None
zstandard : None
tzdata : 2023.3
qtpy : None
pyqt5 : None

[rhshadrach]

Thanks for the report! You can also pass sort=False to groupby the avoid the sorting.

No opposition to adding the exception here, but I wonder how many more edge cases like this exist. We currently try to be pretty flexible in handling a variety of types where I think most other sorts would just raise. A bit tangential, but I'm thinking we should decide what mixture of objects we support and document this. In this regard, I think Decimal (with NA values) makes sense to include.

[stevenlandis-rl]

Using sort=False worked perfectly for my use case. Thanks!

[rhshadrach]

@jbrockmendel - curious on your thoughts here on whether we should support sorting with Decimal mixed in with other dtypes (most notably, NA values).

[jbrockmendel]

Hopefully long-term users with Decimal use cases will use the pyarrow decimal dtypes (and get way better perf). More generally, my intuition is that the invalid comparison should raise TypeError (or a decimal-specific subclass) which should ideally be changed upstream. But that is unlikely to happen anytime soon, so in the interim catching the decimal-specific exception here makes sense (and better than a Just Catch Everything approach we had in days gone by).

(I think IncompatibleFrequency has a similar issue with being a ValueError when it really should be a TypeError.)

[rhshadrach]

@jbrockmendel - I vaguely recall you mentioning reporting this upstream to CPython at some point. Is my memory correct? If not, I can.

[jbrockmendel]

i dont think i ever reported it upstream, no

[rhshadrach]

I took a deeper look into this, it appears TypeError would not be appropriate here.

 print(Decimal(5) < float("nan"))
# raises decimal.InvalidOperation: [<class 'decimal.InvalidOperation'>]

The issue isn't the type, it's that Decimal by default has much more strict exception raising than floating point numbers when it comes to "invalid" operations.

https://docs.python.org/3/library/decimal.html#signals

You can disable these traps to have math operate more like IEEE 754:

decimal.getcontext().traps[decimal.InvalidOperation] = False
print(Decimal(5) < float("nan"))
# False