String dtype: keep select_dtypes(include=object) selecting string columns #62323
Conversation
There was a problem hiding this comment.
Thanks @jorisvandenbossche
I'm not sure i see it in the accompanying issue, but what if a user just wants object columns when str columns are also present in 3.0.
I see that you plan to add a warning
When a user does select_dtypes(include=[object]) in pandas 3.0, and we see that there are str columns, raise a warning mentioning to the user they likely want to do include=[str] instead.
| else: | ||
| e = df[["a", "b"]] | ||
| # if using_infer_string: | ||
| # TODO warn |
There was a problem hiding this comment.
in the issue you said And in any case, we should probably still add a warning to pandas 2.3 about this when the string mode is enabled (for if we do a 2.3.2 release)
so this TODO should this be part of this PR?
There was a problem hiding this comment.
This PR just restores the old behaviour, and in that case we don't need to warn, I think. We should add a warning that "object" will stop selecting string columns at some point, but in any case I want to only do that in a later PR because that is a lot more complicated.
It was for the case that we decided to keep the current-main behaviour of object not selecting string columns that we should have definitely added a warning to warn users that they are not getting the result they are expecting.
Yeah, it's noted at the bottom of the top comment in the issue: that's the annoying part that now that we do distinguish object and str columns, one might want to select only the object columns, and that is not yet really possible (as with this PR you also get the string columns) or would give a warning you have to ignore (once we add a warning to deprecate). |
|
could |
|
Ah, yes, we should ensure that works fine without warning, then that would be a good workaround! |
The backwards compatibility part of #61916