Numpy-compatible typevars in array classes?

[sneakers-the-rat]

Describe the new feature you'd like

Hello!

I work on a package for backend-arbitrary array validation, and part of that is providing generic type annotations for NDArrays.

I'm in the process of updating our type annotations and updating zarr handling from 2->3, so i'd like to improve zarr typing support while i do so.

I'm wondering if you'd be willing to add numpy-compatible typevars for arrays?

The NDArray typevars could live alongside the current metadata typevar, I can't really quite tell how those work - typically it's not possible to use callables like dataclasses in type annotations since they can't be statically analyzed, and i don't see them getting declared (i could be missing things!).

Currently the most common type that's returned from constructors is AnyArray which sets the generic as Any, so I can e.g. set dtype there without mypy complaining, but numpy's type annotations have the form:

np.ndarray[tuple[Any, ...], np.dtype]

with shape as a tuple and a dtype.

so zarr's arrays could be like

Array[tuple[Any, ...], np.dtype, ArrayMetadata]

Just having the generics be there for downstream consumers to declare would be plenty for me, it would make it possible for me to keep the base type of zarr arrays while also declaring shape and dtype annotations in a mypy plugin, rather than doing what i have to do now which is hack it together with a np.ndarray type which masks the unique methods in zarr arrays (which are important!)

Thanks! I'd be totally happy to implement this if it would be accepted.

[d-v-b]

yeah I think we are open to adding this information! might also be worth weighing the value of defining some fixed-size arrays with a checked dimensionality, like Array3D, where the shape is Literal[3]. You should probably do a first pass over our codebase and check if we are doing anything that makes threading the type parameters difficult.