-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
API/TST: Call __finalize__ in more places #33379
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
API/TST: Call __finalize__ in more places #33379
Conversation
Progress towards pandas-dev#28283. This adds tests that ensures `NDFrame.__finalize__` is called in more places. Thus far I've added tests for anything that meets the following rule: > Pandas calls `NDFrame.__finalize__` on any NDFrame method that returns > another NDFrame. I think that given the generality of `__finalize__`, making any kind of list of which methods should call it is going to be somewhat arbitrary. That rule errs on the side of calling it too often, which I think is my preference.
CI has finished here, just hasn't updated on the UI. On the call yesterday, people generally seemed OK with the rule that methods returning NDFrames should call Does anyone have issues with the structure of the If so, I'll start to work on the xfails (methods that don't yet call |
nice work @TomAugspurger |
if annotate in {"left", "both"} and not isinstance(right, int): | ||
right.attrs = {"a": 1} |
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.
Hi @TomAugspurger - I don't suppose you remember, but was this meant to be
if annotate in {"right", "both"} and not isinstance(right, int):
right.attrs = {"a": 1}
?
EDIT so sorry, just noticed you'd confirmed this in #34373 (comment) . Please ignore my comment, sorry for the noise
Progress towards #28283. This
adds tests that ensures
NDFrame.__finalize__
is called in more places.Thus far I've added tests for anything that meets the following rule:
I think that given the generality of
__finalize__
, making any kind oflist of which methods should call it is going to be somewhat arbitrary.
That rule errs on the side of calling it too often, which I think is my
preference.
For reviewers I think the two most helpful pieces would be
NDFrame -> NDFrame
should call__finalize__
?If you don't agree with the general rule, then we'll need to go through method by method and determine whether that method should call
__finalize__
.Once we have agreement that the tests I've added accurately reflect the desired outcome, this can be merged and we can fix
xfails
in smaller batches.