On Mon, Feb 13, 2023 at 11:33 AM Sebastian Berg <sebastian@sipsolutions.net> wrote:
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)
Those all seem to fit indeed.
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.)
Okay, as long as we keep in mind that it should contain all these not-for-main-namespace functions/classes, it seems fine with me. We can live with two namespaces (`types` and `exceptions`), but more would get a bit too much. We were planning to use `np.lib.*` for more detailed user-facing functions that didn't belong in the main namespace, so let's make sure that we don't end up with >2 of these kinds of namespaces right below the top level one. Cheers, Ralf
- 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