@gmarkall Many thanks for catching that. Glad it was an easy fix. I’ll go ahead and update the code in the post that I linked to above with this fix (in case someone else ends up there first). (Woops looks like it’s too old to do that… perhaps someone with admin access could). I suppose these kinds of issues are inevitable with workarounds like these that get really deep into the guts of things.
@yangeorget I think the “official” way to do this would be to use numba’s typed List filled with first-class functions (which would have the requirement of needing the same signature). Getting that to work—quite frankly—takes a similar amount of type finessing as what you have and unfortunately would introduce a non-negligiable amount of overhead both on the Python side to prepare and pass the List and on the numba side in the performance critical parts of your code—at least its quite a bit of overhead relative to, let’s say doing the same thing in C/C++. A while back I had a very detailed discussion here with @esc about the sources of this overhead. If I had time I’d write a PR… but alas.
If you’re using the workaround with numpy arrays, on the other hand, you’re pretty darn close to the fastest way I could think of implementing this in C/C++ (just with fewer compile-time guarantees from type checking). I suspect that this approach, while decidedly fast, will stay in non-standard land for quite a while. Treating an int64 or uint64 as a weak untyped pointer is all well and good if you know what you’re doing, but is nightmare fuel for a dev team trying to make sure numba users never get a segfault in place of a proper error message.