On Sat, 2023-02-11 at 11:24 +0000, Ralf Gommers wrote: > On Fri, Feb 10, 2023 at 5:35 PM Nathan <nathan.goldb...@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-le...@python.org > > > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > > > Member address: nathan12...@gmail.com > > > > > _______________________________________________ > > NumPy-Discussion mailing list -- numpy-discussion@python.org > > To unsubscribe send an email to numpy-discussion-le...@python.org > > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > > Member address: ralf.gomm...@googlemail.com > > > _______________________________________________ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: sebast...@sipsolutions.net _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
