-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
Deprecate fill_value argument for df.add #32608
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
Some questions / possible counter-arguments:
|
+1 to all of Joris' questions.
FWIW, I've found this behavior useful in the past (if not immediately obvious). |
Strength of my opinion: I agree with Will, but wouldn't have brought it up on my own. FWIW1: We have a total of 6 tests that pass FWIW2: the place I've found this most troublesome is with complex dtypes, where numpy's behavior doesnt match the builtin complex. (xref #28050)
I think that is the idea, yes, on both.
Do we have an idea how often this is used? I agree that if a user wants this, there isnt a simple "do X instead". |
Yea I was thinking across the board deprecation
Maybe @TomAugspurger can offer more insight, but what use cases are there for this? Would have never thought to use this as a quasi-XOR fillna
Yes I think would make sense to do across the board if we wanted to do at all |
This comment has been minimized.
This comment has been minimized.
I thought I'd jump in as I'm using this feature a lot at the moment. Maybe it is a very special case, but there it is important if operating (add, sub, mul, div) with two dataframes with same index and columns that the result distinguishes whether both values are NaN (resulting in NaN), only one (use fill_value) or neither. On this topic I found the following behavior curious: I know in the second example I subtract a pd.Series but I find it strange. |
@WillAyd shoould we add this to the agenda for tomorrow's call? |
Sure! Not a huge sticking point for me but can always be discussed if there is interest.
FYI I probably won’t be able to make tomorrow’s call
… On May 12, 2020, at 4:23 PM, jbrockmendel ***@***.***> wrote:
@WillAyd <https://github.com/WillAyd> shoould we add this to the agenda for tomorrow's call?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#32608 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEU4UPDKFEFOUTGHMI6RITRRHK5NANCNFSM4LFL7DAA>.
|
Another option is to enable the case that currently raises NotImplementedError (i.e. One way to do that would be to tile the series to the same shape as the frame and then use the frame path. Easy+cheap for non-EA dtypes. Would be the same for EA with 2D EAs. For EAs we can cobble together a non-copying solution for axis=1, but that doesnt work for axis=0. |
This came up in the submission for #13488
This is a documented argument but strangely not universally implemented for all argument types. Both @jbrockmendel and I agreed it is probably better to deprecate and push users towards using something like what @jreback suggested in #13488 (comment)
The text was updated successfully, but these errors were encountered: