On Tue, Apr 13, 2021 at 6:58 AM Cecil Curry <leycec@gmail.com> wrote:
This includes popular numerical frameworks one might erroneously assume from
their names to be Python-specific like PyTorch. Despite the name, PyTorch is
also implemented as a low-level Python-agnostic C++ layer
(https://pytorch.org/tutorials/advanced/cpp_frontend.html). The same goes for:

* The entirety of TensorFlow's core C++ API
  (https://github.com/tensorflow/tensorflow/blob/master/tensorflow/core/framework).
* *Most* but not all of NumPy's core C API
  (https://numpy.org/doc/stable/reference/c-api/coremath.html), which NumPy
  developers are desperately refactoring to be Python-agnostic. I believe the
  core "numpy.core._multiarray_umath.ndarray" type is still Python-specific,
  but that's likely to change sometime this decade. (Don't quote me on that.
  Please. My GitHub karma can only take so many body blows.)

As a member of the NumPy core team, let me set the record straight: NumPy is not and will never be Python agnostic. NumPy's internals are specialized to Python's C API. There are many wonderful multi-language numerical computing frameworks, but NumPy is not one of them. I'm not sure where you got this idea but it isn't true.

From a performance perspective, I doubt there are any fundamental issues. Python itself (since Python 3.9) comes with quite a few types defined in C that support type annotations. The ndarray objects in NumPy and other numerical computing frameworks are quite similar in spirit and implementation to Python's built-in types.

Your extensibility concerns are legitimate, but they aren't really specific to multi-dimensional arrays. The data structures behind NumPy have been around for decades, again just like Python's builtins.