POC: aggregate always aggregates #40275
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Proof of concept to show what it would take for #35725 (needs tests, docs, and some comments cleaned up). I wanted to make sure the desired behavior has a viable path before deprecating. I'm planning to put up a PR to deprecate for #35725 in the next week or so, but since this seems to be a somewhat substantial behavior change, I'm wondering if it should be behind an option so that users can opt-in earlier and restore previous behavior for at least 1 release after the deprecation takes effect.
This makes any call to
*.agg
aggregate. For example:will return a Series with 2 rows whose entries are Series themselves. On master, this would be a no-op. Some notes:
df.agg
call passes different things to a custom function depending on whether a unused kwarg is supplied or not #39169, ValueError: Must produce aggregated value, if DataFrame contains a DataFrame as an element #39436