On Fri, 2023-02-10 at 10:34 -0700, Nathan wrote:
On Fri, Feb 10, 2023 at 3:31 AM Sebastian Berg < firstname.lastname@example.org> wrote:
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.DTypeMeta (the metaclass used, just to have it
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
We tried discussing it in the community meeting today and it led to bike-shedding. So lets see if a poll can give an idea for a preferred color:
Happy to add more options (or just get posts there). I don't care too much overall about the where, I just feel it is well time to put it somewhere.
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] 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.)
NumPy-Discussion mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: email@example.com
NumPy-Discussion mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: firstname.lastname@example.org