On Sat, 2023-02-11 at 11:24 +0000, Ralf Gommers wrote:
> On Fri, Feb 10, 2023 at 5:35 PM Nathan <nathan.goldbaum@gmail.com>
> wrote:
>
<snip>

> > >
> >
> > 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.


Well, right now I care mainly about dtype related types.   Other
possible ones might be:
* np.ufunc  (just because I doubt it is used much at all)
* the array-function dispatcher  (private right now)
* DTypeMeta (dtype related, though)

But, not sure we have many more.  I don't think I mind `exceptions` to
be a separate namespace it seems nice and clear?  For the rest, either
a dtype specific solution or not is fine by me.

I suggested types because Python has `types` as a catch-all for builtin
types (mainly function, generator, ...) that are not normally used
directly and it seemed relatively clear and concise.
(In Python I don't think it has anything to do with typing directly.)

- Sebastian


>
> 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
> >
> _______________________________________________
> 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