Support `numpy.typing.NDArray` in `st.from_type()`

[Zac-HD]

I found some notes about numpy.typing with @rsokl a while ago, and thought it worth an issue. @honno might also be interested.

• ArrayLike... except that this is a Union, and we can't register unions
• DTypeLike... also a Union
• NBitBase and specific-width subclasses... meaningless on it's own; would need to register strategies for the generics that take them, i.e. np.floating, np.integer, etc.
• NDArray - finally, something we can handle! Generic class representing an ndarray, takes a dtype specifier.

Maybe we can do something about the Union limitation by understanding TypeAlias? I don't think this information actually exists at runtime, though if it did we could also get better reprs out of it. As a related question we thought that our registration logic for TypeVar might be too permissive.

It would also be nice to distinguish shape: Tuple[int, ...], so that we could generate only positive ints, length-bounds, etc. (likely just by using the array_shapes strategy). However, making the type resolution logic name-aware would open a huge can of worms and complicate the mental model enormously. If we support this, it should be via the explicit Shape: TypeAlias = Tuple[int, ...] and st.register_type_strategy(Shape, npst.array_shapes()) instead.

[Cheukting]

Any update on this issue? I will have a look

[Zac-HD]

The latest state is as written above 🙂

[Cheukting]

Beware! PR on the way

[Zac-HD]

Closing this because I think that https://github.com/HypothesisWorks/hypothesis/pull/3670 went about as far as is reasonable 🙂