ENH: Expand abstract DType hierarchy by seberg · Pull Request #31755 · numpy/numpy

seberg · 2026-06-25T16:43:06Z

Introduces NumericAbstractDType and a fuller numeric "kind" tree mirroring the array-API hierarchy:

NumericAbstractDType
    IntegerAbstractDType
        SignedIntegerAbstractDType
        UnsignedIntegerAbstractDType
    InexactAbstractDType
        FloatAbstractDType
        ComplexAbstractDType

The new abstract DTypes are exposed on numpy.dtypes and the legacy concrete DTypes inherit from them so isinstance/issubclass reflect the kind hierarchy.

Adds register() on abstract DTypes for legacy/user-defined DTypes to opt into a kind, with custom __subclasscheck__ / __instancecheck__ on the metaclass consulting the registered cache and the NPY_DT_NUMERIC flag.

np.isdtype now uses and accepts DType classes (including these abstracts), although passing a non-instance as first argument is deprecated as I think it is a bit wonky.
(Do allow the scalar types as they map OK, but... really that shouldn't be the normal use-case, I think.)

(I used a bit of AI to implement some larger patterns, and some of the tests are; I'll go through once more myself as well.)

jorenham · 2026-06-25T17:12:40Z

I don't think it's possible to make this type-safe; because there's no mechanism to "tell" static-type checkers that some registered custom dtype should be assignable to the relevant absract dtype if that custom dtype isn't an actual subclass of it.

This is why using the register method from abc types is often discouraged, and is also why the static types of collections.abc and stdlib subclasses thereof are such a mess today.

The abstract dtypes themselves seem like a good idea to me though, it's just the register and __isinstance__ magic that I'm against.

jorenham · 2026-06-25T17:16:13Z

Naming-wise, should FloatAbstractDType -> FloatingAbstractDType, and ComplexAbstractDType -> ComplexFloatingAbstractDType, for consistency with np.floating / np.complexfloating? Similarly it would be more consistent to call NumericAbstractDType -> NumberAbstractDType so that it matches np.number I think

seberg · 2026-06-25T17:35:14Z

The abstract dtypes themselves seem like a good idea to me though, it's just the register and isinstance magic that I'm against.

Hmmm, maybe we don't need it strictly, although it is nice to tape over things for old-style dtypes. But... I hope to move ml_dtypes so maybe that doesn't actually matter too much if you think register is too super annoying.

One nice thing about registering (in the future) is that it allows easy creation for custom "superclasses" that also match NumPy if you want to and that can be very nice for promotion logic (i.e. to spell out Int64DType|MyDType). But... maybe we can spell that in a different way nicely, and then I am not sure it matters too much to allow .register().
(I somewhat like it to be the same as the abc, but I guess ABC predate typing, etc...)

ComplexFloatingAbstractDType

Yeah, I would prefer that, we just already ahve it in C... Maybe we can just add an alias there for now...

seberg · 2026-07-18T09:57:21Z

Updated this and renamed the Python side for now only. .register() is removed but for now the Numeric flag is special-cased for subclasscheck (i.e. quaddtype uses it).

(So maybe I am not 100% sure if there isn't some follow-up, but I think this should be ready -- although I should probably go through once more myself due to that back and forth.)

jorenham

don't forget about the numpy.dtypes stubs :)
https://github.com/numpy/numpy/blob/7e1f94485495485c5cc3a408ab9e945940f1b91f/numpy/dtypes.pyi

jorenham · 2026-07-22T17:36:40Z

don't forget about the numpy.dtypes stubs :) 7e1f944/numpy/dtypes.pyi

(or, if you prefer, I could also write them)

seberg · 2026-09-14T16:37:06Z

Sorry that this was not updated for a while. @jorenham I now pushed an update, the types are pretty much added by claude, they seemed reasonable, but can you take a look?

I changed things now to:

Adopted your names, it makes sense to stick to the old ones in Python... (without even thinking much about what is nicer...)
Rip out register as much as I like it, I guess we should be able to get away without it mostly. This simplifies things a lot of course.
For now I removed the fast-path to check the flag
There is a fun thing where our _is_numeric flag is true for booleans but it's excluded from NumberAbstractDType. We may want to move away from that at some point.

Introduces ``NumericAbstractDType`` and a fuller numeric "kind" tree mirroring the array-API hierarchy: NumericAbstractDType IntegerAbstractDType SignedIntegerAbstractDType UnsignedIntegerAbstractDType InexactAbstractDType FloatAbstractDType ComplexAbstractDType The new abstract DTypes are exposed on ``numpy.dtypes`` and the legacy concrete DTypes inherit from them so ``isinstance``/``issubclass`` reflect the kind hierarchy. Adds ``register()`` on abstract DTypes for legacy/user-defined DTypes to opt into a kind, with custom ``__subclasscheck__`` / ``__instancecheck__`` on the metaclass consulting the registered cache and the ``NPY_DT_NUMERIC`` flag. ``np.isdtype`` now uses and accepts DType classes (including these abstracts), although passing a non-instance as first argument is deprecated as I think it is a bit wonky. (Do allow the scalar types as they map OK, but... really that shouldn't be the normal use-case, I think.)

…sure

…ary case)

jorenham

Looks a lot better now; nice.

I left some typing-related comments, most of them about stuff that can be removed.

jorenham

Typing changes look good now, thanks!

mattip · 2026-10-11T14:32:29Z

LGTM. This needs a release note

seberg · 2026-10-15T17:32:01Z

Sorry, finally added a brief release note (and resolved merge conflict).

mattip · 2026-10-15T18:07:40Z

The doctest failures are due to this PR.

mattip · 2026-10-16T10:24:21Z

Thanks @seberg

seberg mentioned this pull request Jul 17, 2026

BUG: add a special case for StringDType in np.isdtype #32030

Merged

seberg changed the title ~~ENH: Expand abstract DType hierarchy and allow register()~~ ENH: Expand abstract DType hierarchy Jul 18, 2026

seberg force-pushed the abstract-dtypes-register branch from dec3b0b to aab2f99 Compare July 18, 2026 09:53

jorenham reviewed Jul 18, 2026

View reviewed changes

jorenham added the 01 - Enhancement label Jul 22, 2026

seberg added 7 commits September 14, 2026 18:39

Rip out register (much simpler of course) and rename Python side expo…

3b22ddb

…sure

Adjust StrinDType isdtype() test for deprecation (and delete unnecess…

5ac3beb

…ary case)

fix style

e254b6e

Smaller fixups and some docs and types/types test

12cf7be

Expand C docs a little and check for bool specifically

0bd3f08

Fixup registration for new module-state

193c506

seberg force-pushed the abstract-dtypes-register branch from 7a65561 to 193c506 Compare September 14, 2026 16:45

jorenham self-requested a review September 14, 2026 17:54

jorenham reviewed Sep 14, 2026

View reviewed changes

Comment thread numpy/dtypes.pyi Resolved

Comment thread numpy/dtypes.pyi Resolved

Comment thread numpy/dtypes.pyi Resolved

Comment thread numpy/dtypes.pyi Resolved

Comment thread numpy/typing/tests/data/pass/dtype.py Resolved

Typing fixups

edfd235

jorenham self-requested a review October 7, 2026 18:52

jorenham approved these changes Oct 7, 2026

View reviewed changes

seberg added 2 commits October 15, 2026 19:28

Merge branch 'main' into abstract-dtypes-register

cce3462

Add minimal release note

08aa171

seberg commented Oct 15, 2026

View reviewed changes

Comment thread numpy/_core/numerictypes.py Resolved

seberg and others added 2 commits October 15, 2026 20:27

Apply suggestion from @seberg

4b74d9c

appease linter

37e509b

mattip merged commit d96ccfe into numpy:main Oct 16, 2026
93 checks passed

seberg deleted the abstract-dtypes-register branch October 16, 2026 10:49

Conversation

seberg commented Jun 25, 2026

Uh oh!

jorenham commented Jun 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jorenham commented Jun 25, 2026

Uh oh!

seberg commented Jun 25, 2026

Uh oh!

seberg commented Jul 18, 2026

Uh oh!

jorenham left a comment

Choose a reason for hiding this comment

Uh oh!

jorenham commented Jul 22, 2026

Uh oh!

seberg commented Sep 14, 2026

Uh oh!

jorenham left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jorenham left a comment

Choose a reason for hiding this comment

Uh oh!

mattip commented Oct 11, 2026

Uh oh!

seberg commented Oct 15, 2026

Uh oh!

mattip commented Oct 15, 2026

Uh oh!

Uh oh!

Uh oh!

mattip commented Oct 16, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

jorenham commented Jun 25, 2026 •

edited

Loading