On Tue, Apr 13, 2021 at 6:58 AM Cecil Curry
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/framewo... ). * *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.