We haven't just thought about it, we intend to do it! :) We're just waiting until we're happy enough with our Numpy array API that we'd be confident in calling

We haven't just thought about it, we intend to do it! :) We're just waiting until we're happy enough with our Numpy array API that we'd be confident in calling it "mostly stable". The (real) Numpy's C API is a perfect example of an API in which gradual accretion of new functions & functionality has given rise to a monstrous (both huge & horrible) API. The naming scheme & parameter patterns are inconsistent; sometimes the names are ambiguous (ie, unclear because they are overly general) or confusing (ie, the function does something other than what you'd expect from the name); and there are several very-similar functions, where it's not always clear which one you should use. I do understand why the Numpy C API has evolved this way: Once you introduce a function in an API, you can't remove it / rename it / change its parameters, or you will break backwards compatibility with your earlier releases and cause headaches for many of your users. (And of course, there are constraints upon an API written in C, that do not affect an API exposed in Python or Nim.) So we're really trying to dogfood our own API as much as possible before we inflict it upon the public. :)