[Numpy-discussion] Introducing `np.types`

2023-02-10 Thread Sebastian Berg
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).


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

(I will note that the DType classes do get printed sometimes in error
messages.)

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: arch...@mail-archive.com


[Numpy-discussion] Re: Introducing `np.types`

2023-02-10 Thread Nathan
On Fri, Feb 10, 2023 at 3:31 AM Sebastian Berg 
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
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-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: arch...@mail-archive.com