-
-
Notifications
You must be signed in to change notification settings - Fork 18k
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
BUG (string dtype): let fillna with invalid value upcast to object dtype #60296
BUG (string dtype): let fillna with invalid value upcast to object dtype #60296
Conversation
Thanks @jorisvandenbossche |
Owee, I'm MrMeeseeks, Look at me. There seem to be a conflict, please backport manually. Here are approximate instructions:
And apply the correct labels and milestones. Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon! Remember to remove the If these instructions are inaccurate, feel free to suggest an improvement. |
…ype (pandas-dev#60296) * BUG (string dtype): let fillna with invalid value upcast to object dtype * fix fillna limit case + update tests for no longer raising (cherry picked from commit 34c39e9)
Manual backport -> #60316 |
Like I did for
replace()
(issue #60282 / PR #60285), it turns out that also forfillna()
we generally upcast to object dtype if the fill value does not fit the dtype:And similarly as for
replace()
, this was raising an error in the case ofStringDtype
.The reason is that for generic (external) ExtensionArrays, we are actually strict and
fillna
is just dispatched to the EA without fallback to object dtype; while for all our own default extension dtypes we do have custom code to ensure to do a fallback (but not for the masked dtypes and ArrowDtype ..).Given this is the default behaviour right now for other dtypes (and so we also haven't deprecated this for current usage of strings in object dtype), I would preserve this fallback for now to avoid this as another breaking change in 3.0.
xref #54792