Type signatures for standardized functions

I think standardized functions should include signatures that are at least in principle compatible with static type checking tools such as mypy, ideally treating dtype and shape as an implicit part of array types. This would eventually allow for static checking of code using these array APIs, which would using these APIs much safer.

This would entail standardizing a number of implementation details beyond those in the current draft specs, e.g.,

• Python types: this is very basic, but we should specify exactly which Python types are valid for various arguments, e.g., axis must use a Python int or tuple[int, ...].
• array types: are operations on an array of some type required to return an array of the same type? Or merely another array (of any type) that also satisfies the standard array API (whatever we eventually define that to be)?
• array shapes: do we require implementing the full version of NumPy broadcasting? Or do we define behavior in simpler cases, e.g., where all shapes match? It might also make sense to only require a more explicit subset of broadcasting behavior, without automatic rank promotion.
• array dtypes: do we include dtype promotion like what NumPy uses? Or do we only define operations on a predefined set of “safe” dtypes, e.g., add(float64, float64) -> float64? One argument against codifying dtype promotion is that the details of dtype promotion are rather tricky, and NumPy’s rules are unsuitable for accelerators (JAX and PyTorch implement incompatible semantics). On the other hand, requiring explicit dtype casting (like in TensorFlow) is rather annoying for users (maybe less of a problem for library code).

[rgommers]

So I want the same static typing (whatever is returned is an array type that adheres to the spec)

actually no, I’m not sure that’s 100% correct. I think the static typing in https://github.com/data-apis/array-api/issues/13#issuecomment-668903281 is useful for array libraries that are happy to do coercion to their own internal array type (numpy would do that), and the right thing to do for consumer libraries that want to support multiple array types. But array libraries should also be free to do:

def arange(x: myTensor) ->  myTensor:
    ...

rather than typing everything as an Array Protocol.

[shoyer]

I think it’s totally reasonable to say that we’ll copy NumPy for broadcasting. There are other ways to catch broadcasting errors (e.g., type checking, at least in principle).