You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
DISCUSS: Consider whether it should be Dtypelike or DTypeLike #16562
The stubs currently add DtypeLike as "anything that can be coerced by np.dtype. However, with new user dtypes, the dtype classes will be the important building-blocks probably. For these I currently use the spelling DType (capital T).
This does not need to affect the stubs, however, it may be that the stubs basically end up using the DType class as the category (i.e. byte order and string length rarely make a difference probably). In this case keeping the spelling between the DType class and the DTypeLike synched up, may make additional sense. Otherwise, being intentionally different may be an argument.
I guess I use the DType capitalization as a short form of camel-case DataType, but I am open to reconsider that as well.
Just a reminder that we should decide on DTypeLike or DtypeLike before 1.20.
All reactions thus far have been positive to the proposed name change, so I'd say lets just switch to DTypeLike.
Activity
BvB93 commentedon Jun 10, 2020
I agree with your assessment. It'd a relatively minor change, but an improvement nevertheless.
person142 commentedon Jun 12, 2020
Have a branch where I'm working on making that happen, so
DTypeLikeseems like the right call to me too.BvB93 commentedon Nov 2, 2020
Just a reminder that we should decide on
DTypeLikeorDtypeLikebefore 1.20.All reactions thus far have been positive to the proposed name change, so I'd say lets just switch to
DTypeLike.BvB93 commentedon Nov 3, 2020
Alright, the pull request is up: #17699.