On Fri, Feb 10, 2023 at 5:35 PM Nathan <nathan.goldbaum@gmail.com> wrote:
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.
I had the same concern. It would be good to have a full list of things to put in this and the scope of it. There's other things that could fit, like custom warning and exception classes. We just added `numpy.exceptions` for the next release, but that could still be moved. Having separate submodules for type classes, for exceptions, for array-function override related stuff, etc. is not great. Enums could fit as well, they're now polluting the main namespace. It seems like we need one namespace with all that kind of stuff that the average end user won't need but that becomes useful/important when you're doing something quite custom or are writing a library on top of numpy. Cheers, Ralf
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] np.types.NumberDType
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 messages.)
See also https://github.com/numpy/numpy/issues/22920.
Cheers,
Sebastian
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: nathan12343@gmail.com
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: ralf.gommers@googlemail.com