ENH: add a hook to the DType API for parsing dtype strings #30699
Description
Over in nanograv/PINT#1944 (comment) and astropy/astropy#19197 we ran into a behavior difference between built-in DTypes and user dtypes: a string representation of a user dtype doesn't round-trip through np.dtype.
Works:
>>> np.dtype(np.dtype(np.int64).str)
dtype('int64')
Doesn't work:
>>> np.dtype(np.dtype(numpy_quaddtype.QuadPrecDType().str))
Traceback (most recent call last):
File "<python-input-4>", line 1, in <module>
np.dtype(np.dtype(numpy_quaddtype.QuadPrecDType().str))
~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: data type "QuadPrecDType(backend='sleef')" not understood
astropy was relying on this round-tripping via dtype.str.
We spoke a little about this during today's triage meeting and we came up with a possible way to make this work.
- Add two new DType API slots.
- The first will be a string or maybe a null-terminated array of strings that a DType passes to NumPy and NumPy can use to decide whether or not an unrecognized string dtype name corresponds to a registered user DType. These strings could be something like
"QuadPrecDType", and if NumPy receivesQuadPrecDType(backend='longdouble'), NumPy sees the beginning of the string is a match and calls the function defined in the second slot with the user-supplied string. - The second will be a function that accepts a string, parses it, and returns a new DType instance.
- The first will be a string or maybe a null-terminated array of strings that a DType passes to NumPy and NumPy can use to decide whether or not an unrecognized string dtype name corresponds to a registered user DType. These strings could be something like
Ping @SwayamInSync @mhvk what do you think of this?