On Fri, Feb 10, 2023 at 3:31 AM Sebastian Berg <sebastian@sipsolutions.net> wrote:
Hi all,

I was wondering if we should introduce a new `np.types` namespace.  The
main reason is that we have the DType classes, that most users don't
need to worry about.  These mirror the scalar classes, but getting them
is weird currently.

I never wanted to put these in the top-level (because I feel they
probably won't be used much day to day).  That would be thing like:

* np.types.IntDType, np.types.Int64DType  (or maybe without dtype)
* np.types.NumberDType  (an abstract DType)
* np.types.InexactDType
* ...
* np.types.DTypeMeta  (the metaclass used, just to have it somewhere)

Maybe there are some more types that we could use a public entrypoint
for  (e.g. the type used by array-function dispatched functions or
`np.ufunc` could in principle move also).

Small bikeshed: the name np.types indicates to me that it has something to do with static typing. If this namespace only includes dtype classes, then np.dtype_classes is a more natural name. If it includes things like `np.ufunc` then that's not as clear, and I don't have a better idea offhand than np.types.

What do you think?  I don't really have a good idea for an alternative
but at some point not making these nicely public is not great...

Related to your proposal but not orthogonal to it, I still think it would still be nice to be able to do things like:

    >>> np.dtype[numbers.Number]

I know that currently __class_getitem__ is used by the typing support, but I think the typing will still work if you also got back a usable dtype instance at runtime instead of a GenericAlias, which has a confusing repr and is not useful at runtime.
(I will note that the DType classes do get printed sometimes in error

See also https://github.com/numpy/numpy/issues/22920.



NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-leave@python.org
Member address: nathan12343@gmail.com