Skip to content

CLN: Catch more specific exception in groupby.ops #28198

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Sep 7, 2019
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 6 additions & 3 deletions pandas/core/groupby/ops.py
Original file line number Diff line number Diff line change
Expand Up @@ -212,9 +212,12 @@ def apply(self, f, data, axis=0):
# This Exception is also raised if `f` triggers an exception
# but it is preferable to raise the exception in Python.
pass
except TypeError:
# occurs if we have any EAs
pass
except TypeError as err:
if "Cannot convert" in str(err):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the type(s) of exceptions that raise this not well defined?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cython raises this (with a message matching this pattern) if we pass a non-ndarray to something expected an ndarray. im not aware of any other cases we actually want to let pass here

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume you saw other non-Cython TypeErrors show up here then?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we dont catch TypeError at all, the only tests that fail are ones where apply_frame_axis0 is raising because it expects an ndarray

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I may have asked this wrong but I don't think we are on the same page. So I was thinking to keep catching TypeError but was questioning if we need the conditional block therein, as it diverges slightly from the pre-existing behavior.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we need the conditional block therein, as it diverges slightly from the pre-existing behavior.

Changing the behavior is intentional. ATM we are passing on everything, and I want to pass on a narrow set of TypeErrors.

# via apply_frame_axis0 if we pass a non-ndarray
pass
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks fine, does this change any perf? IOW this looks like this is now taking a path that previously we raised (and then likely did an .apply on)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure. Between this, #27909, and a not-yet-pushed branch that fixes incorrect exception handling in cython_agg_block, I'm pretty sure we'll end up falling back to python-space less often, but it isn't obvious what the individual changes affect perf-wise.

else:
raise

for key, (i, group) in zip(group_keys, splitter):
object.__setattr__(group, "name", key)
Expand Down