26.08.2015, 14:14, Francesc Alted kirjoitti: [clip]
2015-08-25 12:03 GMT+02:00 Nathaniel Smith <njs@pobox.com>:
Let's focus on evolving numpy as far as we can without major break-the-world changes (no "numpy 2.0", at least in the foreseeable future).
And, as a target for that evolution, let's change our focus from numpy as "NumPy is the library that gives you the np.ndarray object (plus some attached infrastructure)", to "NumPy provides the standard framework for working with arrays and array-like objects in Python"
Sorry to disagree here, but in my opinion NumPy *already* provides the standard framework for working with arrays and array-like objects in Python as its huge popularity shows. If what you mean is that there are too many efforts trying to provide other, specialized data containers (things like DataFrame in pandas, DataArray/Dataset in xarray or carray/ctable in bcolz just to mention a few), then let me say that I am of the opinion that there can't be a silver bullet for tackling all the problems that the PyData community is facing.
My reading of the above was that this was about multimethods, and allowing different types of containers to interoperate beyond the array interface and Python's builtin operator hooks. The exact performance details of course vary, and an algorithm written for in-memory arrays just fails for too large on-disk or distributed arrays. However, a case for a minimal common API probably could be made, esp. in algorithms mainly relying on linear algebra. This is to a degree different from subclassing, as many of the array-like objects you might want do not have a simple strided memory model. Pauli