Skip to content

DISCUSS: Consider whether it should be Dtypelike or DTypeLike #16562

Closed

Description

@seberg

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.

Activity

  1. added this to the 1.20.0 release milestone on Jun 10, 2020
  2. BvB93 commented on Jun 10, 2020

    @BvB93
    Member

    I agree with your assessment. It'd a relatively minor change, but an improvement nevertheless.

  3. person142 commented on Jun 12, 2020

    @person142
    Member

    however, it may be that the stubs basically end up using the DType class as the category

    Have a branch where I'm working on making that happen, so DTypeLike seems like the right call to me too.

  4. BvB93 commented on Nov 2, 2020

    @BvB93
    Member

    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.

  5. BvB93 commented on Nov 3, 2020

    @BvB93
    Member

    Alright, the pull request is up: #17699.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions