Personally, I would prefer that Numba does not read my variable annotations. The reason is that I currently use mypy to check my code (so I want to annotate), but I donāt want to declare the inputs to my jitted functions.
Numba does an excellent job in figuring the types of the inputs, and compiling correctly based on that. I donāt think there are many cases in which manual annotations are superior (for the njit decorator).
Explicit typing is mostly unnecessary, in some case it is harmful (many people fall for the float64[:] trap), and in some cases impossible (eg structured arrays created out of csv files).
Numba is different from Cython where annotations improve performance. Thereās no performance benefit to annotations in Numba njit (cfunc is a different problem).
Disagree, I have experience with many languages (C, C++, Java, C#, Python, even JavaScript and TypeScript) and I have found a lots of benefits with using annotation that allow me to find issues earlier
Python so powerful that they allow express even something like concepts in C++ World, meaning they allow to say that argument could be any type that implement some functionality like Iterator
Maintaining two annotation systems sometime good, but some time Numba could just check if argument annotated with python int then apply some optimization and generate code
Anyway I do want only provide annotations as alternative to njit
@redradist, I am not sure on what you are disagreeing with. You said that annotations allow to find issues earlier, and I said that I ācurrently use mypy to check my codeā. So we are in agreement there.
What I said next is that mypy annotations are useful, but Numba explicit typing is most of the time not necessary, ie I would write functions like this:
@njit
def foo(x: int):
return 1
Writing like this is currently valid in Numba, and it that allows mypy to perform static typing, and allows Numba to do type inference on the inputs, and you get the best of both worlds.
Are you disagreeing with my statement that Numba inputs do not need type declarations most of the time?
Thanks for clarifying. How would you express array inputs? I donāt think mypy has a way to write float64[:,:].
One of my points was that @njit("int32(int32)") is mostly unnecessary and @njit is the better option in many use-cases (probably most use cases). What would happen in your proposal if someone writes
@njit
def f(x: int) -> int:
Would Numba read that annotation or ignore it?
The point is that you donāt need to support two annotations, because ("int32(int32) can be omitted most of the time.
class float64: # Custom annotation class
def __getitem__(self, item):
# Some value should be set to identify that float64[:], float64[:,:] or etc.
return self
float64 = float64()
def for_loop(n: float64[:,:]):
pass
Iām not expert in the topic but I think mypy still has problem expressing certain types, especially regarding numpy arrays. all these issues are still open:
For example, I think integer generics are necessary to describe Numbaās UniTuple type.
Python annotations is just an object (any object) that express intent ā¦
You can just make yourās annotations and when issue with mypy annotation will be fixed, just to switch to mypy annotation
Iāve just created one for you