Deprecate creation of dtypes via np.dtype('typename')

[jakevdp]

See numpy/numpy#24699

I suspect this is also going to break a lot of JAX code as well...

[ngoldbaum]

For what it's worth, if the deprecation I proposed does go through, the string type names will still work for builtin numpy dtypes, just not ones added via the sctypeDict.

[jakevdp]

Thanks for the clarification – understood. But in tensorflow and jax, we have 4+ years of legacy code written in a context where np.dtype('bfloat16') does not error, so I suspect this deprecation will bring some amount of pain downstream.

[ngoldbaum]

As @hawkinsp pointed out in the NumPy repo, adding these dtypes to NumPy itself would also fix the problem, since hopefully jax users don't care if the dtype is defined inside NumPy or in an extension. It would probably need a NEP and a reference implementation but I think the existing downstream usage by jax proves out a real need and if we can inherit names that are already used by jax that also avoids some bikeshedding.

I would hope it should be relatively straightforward to write these dtypes using the new dtype API since they are non-parametric and have a straightforward binary layout and cast definitions. The devil is in the details, of course...

I proposed adding a new dtype to NumPy written using the experimental dtype API in NEP 55. If that NEP is accepted and the code is upstreamed it should be much clearer how to integrate dtypes written outside of NumPy into NumPy itself.

Of course all of this is just my opinion so far, I'll wait to weigh in more until others from NumPy have weighed in about the sctypesDict deprecation.

[jakevdp]

For what it's worth, we created ml_dtypes on the recommendation of Numpy maintainers in this thread, with the hope that the bfloat16 implementation might someday be upstreamed into NumPy if the community supported it.

The float8 and int4/uint4 types are a bit more experimental, and probably not suitable for inclusion in NumPy until they gain more traction.