BUG (string dtype): let fillna with invalid value upcast to object dtype #60296
+6
−16
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.
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