-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
DOC: clarify dangers of fast apply in GroupBy apply docs #14180
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
Comments
mutation is simply not a good idea on groupby fast apply is an impl detail |
I think #13543 might be related, although the opposite problem (fast works as expected, slow does not) |
pdpark
pushed a commit
to pdpark/pandas
that referenced
this issue
Jan 7, 2018
…ly" section of groupby.rst Resolves: pandas-dev#14180
1 task
pdpark
pushed a commit
to pdpark/pandas
that referenced
this issue
Jan 10, 2018
pdpark
pushed a commit
to pdpark/pandas
that referenced
this issue
Jan 10, 2018
1 task
pdpark
pushed a commit
to pdpark/pandas
that referenced
this issue
Jan 12, 2018
pdpark
pushed a commit
to pdpark/pandas
that referenced
this issue
Oct 16, 2018
fast_apply has been removed; closing |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I recently had to solve an issue where some code was behaving inconsistently. Effectively, I tracked this issue to a function that was being passed to apply which occasionally, under certain circumstances, mutated the input for a group - and not always the first group. Because fast_apply only checks the first group this meant that the output was unreliable. It didn't take me long to work out, but from a user's point of view it would be good to extend the docs so that they clarify that mutating the input is either not a good idea, or it should occur consistently for each group (or at the very least always for the first group).
The text was updated successfully, but these errors were encountered: