MAINT: dtype.name works for NEP 42 dtypes #23047
Conversation
61d82aa to
65410ee
Compare
65410ee to
2a5f735
Compare
There was a problem hiding this comment.
Thanks, works for me and the test is sufficient to follow-up if we modify the kind logic. It would be good to find a better story about it (because likely kind should be something other than \00, although not sure what).
If you have a good idea to improve, lets just follow up.
| @@ -348,7 +350,9 @@ def _name_get(dtype): | |||
| # user dtypes don't promise to do anything special | |||
| return dtype.type.__name__ | |||
|
|
|||
| if issubclass(dtype.type, np.void): | |||
| if dtype.kind == '\x00': | |||
There was a problem hiding this comment.
We really should improve thi. Right now I have type(dtype)._parametric and _abstract. I am thinking it might make sense to make these public and (maybe without the underscore).
Could also add it to the dtype instances. I think we can consider these attributes stable API really (maybe even already with that underscore).
There was a problem hiding this comment.
Yeah, I think having a concrete and obvious way to signal that this is a new-style dtype would be great. I don't have a strong opinion about how that should be spelled.
There was a problem hiding this comment.
I don't have a strong opinion about how that should be spelled.
If not you, who then? :). More seriously though, we have to make these public in some form I think. And if we are unsure, a safe bet is to just keep it as is (with an underscore), but define it as stable API (and maybe document it).
There was a problem hiding this comment.
Is there a logical test on dtype._parametric and dtype._abstract that can be used to get the same information as checking dtype.kind == '\x00'?
Because there are legacy parametric and abstract dtypes I'm not sure there is, so making these attributes public is might be orthogonal to this discussion.
That said, I agree making them public would be useful.
Maybe just adding a new check in arraydescr_isbuiltin_get and allow dtype.isbuiltin to be 3? If new public attributes on dtype instances are OK, it could also be a new attribute which is only True for dtypes are created through the public dtype API. I guess naming is a tad awkward because of the existence of legacy user dtypes, but something like dtype.is_nonlegacy_custom maybe?
There was a problem hiding this comment.
Returning 3 there seems OK, the only danger is if someone out there did dtype.isbuiltin != 2 or something crazy. But that seems unlikely?! dtype.iscustom is maybe not so bad (I would just ignore the "legacy" part and assume legacy dtypes will die off eventually?)
I do think we need this information also on the type probably in the long term. One other way to do this is always isinstance/issubclass(..., np.UserDType). That would probably make Marten very happy I am sure ;). I do not see that such APIs as mutual exclusive, though.
Closes #22900
dtype.nameis used by downstream libraries when introspecting dtypes. In particular pandas does this.It's relatively straightforward to define
namebased on the dtype class'__name__.Note that the check for whether
dtype.type is Nonein_name_includes_bit_suffixis only needed for the_ScaledFloatTestDTypetest, but I guess in principle dtype.type could beNonein a real dtype?