BUG: add a special case for StringDType in np.isdtype - #32030
Conversation
|
Note that this would be superseded by gh-31755, but I need to file it (and make a decision if we expose But as always, that doens't mean we can't just do this now :). |
seberg
left a comment
There was a problem hiding this comment.
Seems simple enough, so happy if you put it in, just a small merge conflict for the other PR.
| # dtype parameters are ignored, like datetime64 units | ||
| assert np.isdtype(np.dtypes.StringDType(na_object=None), dt) | ||
| assert np.isdtype(dt, np.dtypes.StringDType(na_object=np.nan, | ||
| coerce=False)) |
There was a problem hiding this comment.
Ah one note: I think I would want to deprecate this. It doesn't actually make much sense, because to ask it for a dtype instance as second argument, IMO.
(Even if it is convenient.)
There was a problem hiding this comment.
If you like to do it for all inputs, but can also do it in the other PR, I dunno how nice it is without the changes around.
There was a problem hiding this comment.
Ah in that case why don't you add the deprecation in the other PR. You have more context here than I do.
BUG: add a special case for StringDType in np.isdtype (#32030)
(cherry picked from commit 7e1f944)
PR summary
Fixes #27545.
I don't see a cleaner way to fix this without just adding a special case in the error path. This function is only for built-in NumPy DTypes so it would be a bigger change to just make it return True if it's handed a dtype or dtypemeta instance, which is probably a more principled fix.
AI Disclosure
No AI use on this one.