I'm not sure I understand the objection to having "too many submodules", but if it's a concern, the exceptions could be added here instead of a separate np.exceptions, since exceptions are themselves just types. 

Aaron Meurer

On Wed, Feb 15, 2023 at 2:33 PM Sebastian Berg <sebastian@sipsolutions.net> wrote:
On Fri, 2023-02-10 at 10:34 -0700, Nathan 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


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:

https://discuss.scientific-python.org/t/where-to-put-dtype-classes/655

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.

- Sebastian



> 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.)
> >
>
> 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: sebastian@sipsolutions.net


_______________________________________________
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: asmeurer@gmail.com