-
-
Notifications
You must be signed in to change notification settings - Fork 18.1k
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
ENH: add groupby & reduce support to EA #22762
Conversation
Hello @jreback! Thanks for updating the PR.
Comment last updated on October 06, 2018 at 14:08 Hours UTC |
Codecov Report
@@ Coverage Diff @@
## master #22762 +/- ##
==========================================
+ Coverage 92.2% 92.2% +<.01%
==========================================
Files 169 169
Lines 50924 50944 +20
==========================================
+ Hits 46952 46972 +20
Misses 3972 3972
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From a quick look: I have the feeling this is exposing too much internals of pandas to EA (eg this basically makes all our nanops implementations public).
We should maybe rethink the _reduce
interface a bit? (I assume now this is basically identical to what we already have defined on series/dataframe?)
@jorisvandenbossche simplified |
pandas/core/arrays/base.py
Outdated
@@ -708,6 +712,25 @@ def _add_comparison_ops(cls): | |||
cls.__le__ = cls._create_comparison_method(operator.le) | |||
cls.__ge__ = cls._create_comparison_method(operator.ge) | |||
|
|||
def _reduce(self, name, skipna=True, **kwargs): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What sort of things go into kwargs? Is it things like ddof
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, they are specific to the reducer
In the meeting, we discussed what error should be raised when an ExtensionArray doesn't implement a specific reduction (e.g. StringArray won't implement |
so we have a base class |
I'm not really sure what's cleanest. If a class implements just some reductions, changing what we do in the base class doesn't won't make a difference. At that point I think it's up to the EA to raise the correct exception for methods they don't support. For classes that don't implement any reductions, we could either raise a TypeError, or put each call in a
but doing that everywhere seems error prone. |
So my earlier comment "On this branch I think a NotImplementedError" may have been incorrect. |
I would do that, because in the base scenario (the EA does not support reductions), users should see a TypeError and not an AbstractMethodError. And if we already raise that in the base implementation, an EA author does not need to do that. |
ok updated to generically raise TypeError on EA's if a reduction operation is attempted and not overriden. |
@jorisvandenbossche updated |
@jreback can you answer to some of my remaining comments? |
can't see to reply above, but that is not possible. you change behavior by pre-filtering, the nan's need to be handled by the nanops routines which already do the special cases (e.g. sum and such), and its just much simpler. |
…oked and not overriden, test the same
@jorisvandenbossche addressed comments & removed some xfailed tests. |
That test looks good. +1 to merge. |
@jorisvandenbossche your commits all look fine. |
I opened #23106 for the return type issue |
@jreback Thanks! |
yeah the return type seems easy but ran into some issues. |
closes #21789
closes #22346
xref #22865