-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
REGR: Fix regression RecursionError when replacing numeric scalar with None #48234
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
Merged
Merged
Changes from 1 commit
Commits
Show all changes
12 commits
Select commit
Hold shift + click to select a range
205c0f0
REGR: Fix regression RecursionError when replacing numeric scalar wit…
phofl 18b4b92
Merge remote-tracking branch 'upstream/main' into 48231
phofl 1d1e98c
Update
phofl 2402196
Restore 1.4.x behavior
phofl a71367d
Fix mypy
phofl 2735ec2
Merge remote-tracking branch 'upstream/main' into 48231
phofl 796b870
Merge branch 'main' into 48231
phofl 42b11cb
Merge remote-tracking branch 'origin/48231' into 48231
phofl 077cd93
Move whatsnew
phofl f1cf6e8
Merge remote-tracking branch 'upstream/main' into 48231
phofl d7c7a9e
Merge remote-tracking branch 'upstream/main' into 48231
phofl 0eb2b08
Merge branch 'main' into 48231
phofl File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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.
it maybe that we do need to add additional logic for now but there has been some prior discussion about this issue cc @jbrockmendel
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.
Yeah this is not a permanent fix, but this happens for every numeric column no matter what value you replace (not only nan), so we should provide a fix before releasing
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.
sure. (unfortunate that #45725 was not labelled as a regression (from main) and that the milestone was removed)
This had a simple fix, which I reverted because of inconsistencies in handling
None
in a list-like and a scalar. Long term we need to address those inconsistencies.any temp fix needs a code comment explaining when/how the code can/should be removed.
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.
quickly looking back, I did open a PR (#46443) that attempted to address the fact that sometimes we want the missing value to be strict.
we have 2 weeks to fix, so happy to discuss all options.
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.
Agreed, would be great if we can come up with a permanent fix
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.
has there been a discussion about the desired behavior? i could imagine having
Series([1, 2]).replace(2, None)
returningSeries([1, np.nan])
. I think that might be the right thing to do internal-consistency-wise.To get that I think we'd use _standardize_fill_value at the top of Block.replace.
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.
If you do
ser.loc[0] = None
this upcasts to object, so imo this would make sense for replace too?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.
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.
Ah that's on me, sorry, I was expanding, e.g. doing
ser.loc[2] = None
which casted to object on 1.4.3. This is obviously inconsistent too. Would be ok with float64 and casting to nan thenThere 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.
IIUC from previous discussions that is the preferred fix. We then need to either special case (or handle differently) the dispatch from the list-like replace, where for backwards compatibility, the
None
replace value is explicit.The reason I reverted the original fix for the RecursionError (on main) is to facilitate the backport fix, where we have less flexibility for changes in behavior. But the intention was that the issue would be fixed before 1.5.
The proper fix for 1.5 may also involve discussion on deprecating the current list-like replace behavior to be consistent with a scalar replace.