Static typing issues with single array element return values

[ARF1]

I have been trying out the new static typing stubs for one of my projects: Great work, thank you! This makes static type checking so much more useful.

There are two issues (or maybe a single underlying issue) I am frequently encountering in my code base:

• When one accesses a single element of a numpy array, it returns an object that behaves like a native object. I.e. for a float array, the result of __getitem__() behaves effectively like a python float: It can be used in standard library functions that take floats. The current numpy typing stubs specify Any as return type which leads to plenty of issues at the intersection of numpy and the standard library.
• Similarly ufunc return types are too wide: E.g. np.log10(10) has return type generic which is incompatible with float even though the return type is static in this case.

Example code:

import numpy as np

x: float = 0.1
y = np.arange(10)

y_element = y[-1]               # has type: Any

z1 = x * np.log10(y_element)
z2 = x * np.log10(10)

Static type checkers complain for both the last two lines like so:

Operator "*" not supported for types "float" and "ndarray | generic"
  Operator "*" not supported for types "float" and "generic"
Operator "*" not supported for types "float" and "ndarray | generic"
  Operator "*" not supported for types "float" and "generic"

I understand the difficulty of typing ufunc in general. That said, it would really be great if this could be made to work.

[BvB93]

The first issue (the return of Anys) is something that we'll unfortunately have to deal with for the time being.
NumPy is a large library that is fairly complex to annotate (e.g. #16546). Getting rid of all remaining Anys will be a matter of time. As for ndarray.__getitem__ specifically: this requires making ndarray generic w.r.t. its dtype, which is a feature planned for the 1.21 release (#17719).

The second issue is definitely a more pressing concern. For know, the only solution is to, unfortunately, is to set the return type to Any.

[ARF1]

@BvB93 Possibly a stupid question: Could the typing of ufuncs be automated by code generation making use of a ufunc's types attribute? This won't help the first issue but it might help generating appropriate overloads for the second issue.

[BvB93]

Could the typing of ufuncs be automated by code generation making use of a ufunc's types attribute?

Absolutely, in fact I have a branch somewhere that does something like that.

[ARF1]

@BvB93 Thanks for letting me know and for all your work on typing numpy!