This pattern is how I wrote the SDE solver in Python. That works great and is really useful and the reason why I teach closures. The library we're building now

This pattern is how I wrote the SDE solver in Python. That works great and is really useful and the reason why I teach closures. The library we're building now though does something different. Something like this: def network_rhs(fs, Network) def rhs(y,t) y2 = np.dot(Network, y) r = empty_like(y) for i, f in enumerate(fs): r[i] = f(y2[i]) return r return rhs > what did you run into that was problematic? For more complex model building the right hand side functions actually make use of fairly complex class hierarchies. That was the major stumbling block. But people also were using dictionaries and other non-numpy data structures and just generally idiomatic Python that is not always supported. Some of that stuff is inherently slow/bad design of course, but it still ended up killing the use of my solver for this project. They are now rewriting in C++, which is absolutely a great choice for their case (and probably would have been viable for us too if we had had more people with a C/C++ background in the team). > passing @numba.jit'd functions to scipy is in the Numba guide I wanted to use scipy.root from numba. Not the other way around. Now if all of the numerical Python community was standardized on numba, a lot of this would not be an issue. Scipys LowLevelCallable is a great step in the right direction. But fundamentally I don't see how you will ever get the different libraries to play together nicely in a performant way. It would require every API to expose numba jitable functions. Last I checked, the only functions you could call from within numba code were other numba functions and the handful of numpy features the numba authors implemented themselves (I remember waiting for dot and inv support). If I have an algorithm by a student implemented on a networkx graph as a data structure I can't just jit that. In Julia it automatically is.