@dovoxi One consideration with @milton 's approach is that the constructor now outputs objects of two different structref types. While they share the same TypeTemplate, the f8 and i8 variants of the structref are not unifiable within numba’s type inference system. So you could certainly use this to instantiate these two kinds of objects on the Python side, and even send them individually into jitted functions as single arguments (jit compilation will build two different specialized endpoints for each type individually). However, you could not, for instance, add objects of these two types to the same list and pass that list into one jitted function. So this solution isn’t quite the same as having a proper union type.
I haven’t used numba much in the last 6 months or so (moved to C++ w/ nanobind in part because of these kinds of issues), but I’m fairly certain that this cannot be achieved in numba without doing some annoying, complex, and not-quite-worth-it tricks that involve treating the arrays as opaque pointers, keeping around some kind of type indicator within each structref object, and casting the opaque pointers back to the appropriate array types as indicated by the type indicator. Or alternatively, having some kind of parent class that defines the type indicator and subclasses with extra typed fields that can be casted to from the parent class. The machinery for that approach is also not directly supported by numba, and requires a lot of specialized code to get working. I talked a bit about that here: Any numba equivalent for casting a raw pointer to a StructRef, Dict, List etc? - #12 by DannyWeitekamp.
If you’re brave enough to poke around for a solution along these lines, I did do something like this in this project. But doing so will have you doing so much non-standard stuff that it will become very difficult to maintain… so hopefully @milton 's is enough for your purposes. Good luck!