Use a gradual shape-type for the AudioData type alias

[jorenham]

I noticed that you're using shape-typing for numpy ndarray types; awesome!

One thing that could help avoid some annoying typing errors, is to use tuple[Any, ...] instead of tupleint, ...] to represent an unknown shape type. That's because tuple[int, ...] is only assignable to tuple[int, ...] and not to e.g. tuple[int]. That's why there's tuple[Any, ...], which doesn't have this issue; it's assignable to tuple types of any length. So with this "gradual" shape-type, users no longer have to explicitly cast it to the "actual" shape type in their code (or # type: ignore it).

FWIW; recent versions of numpy (>=2.1) also use tuple[Any, ...] as shape-type of numpy.typing.NDArray for this reason.

[bastibe]

This is related to #484. Since you are a user of type annotations, I would love to get your input on the typing situation in general.

[jorenham]

To be honest I'm not a direct user of these annotations. I stumbled upon this while improving the annotations of librosa, which has soundfile as a dependency.

In #484 there indeed is a similar change, where AudioData is changed to use NDArray instead. For recent numpy versions (>=2.1) that would be equivalent to the change from this PR. For older versions of numpy, it's not. So since you don't seem to have a lower bound on the required numpy version, I'd say that this approach is the more robust one.

[cclauss]

Linting rules for annotations might be of interest…
https://docs.astral.sh/ruff/rules/any-type

https://docs.astral.sh/ruff/rules/#flake8-annotations-ann

https://docs.astral.sh/ruff/rules/#numpy-specific-rules-npy

% ruff check --select=ANN,NPY --statistics

 64	ANN001 	[ ] missing-type-function-argument
  7	ANN201 	[ ] missing-return-type-undocumented-public-function
 30	ANN202 	[ ] missing-return-type-private-function
  2	ANN204 	[ ] missing-return-type-special-method
  4	ANN401 	[ ] any-type