On Tue, Oct 30, 2018 at 2:22 PM, Stephan Hoyer <shoyer@gmail.com> wrote:
The Liskov substitution principle (LSP) suggests that the set of reasonable ndarray subclasses are exactly those that could also in principle correspond to a new dtype. Of np.ndarray subclasses in wide-spread use, I think only the various "array with units" types come close satisfying this criteria. They only fall short insofar as they present a misleading dtype (without unit information).
How about subclasses that only add functionality? My only use case of subclassing is exactly that: I have a "bounding box" object (probably could have been called a rectangle) that is a subclass of ndarray, is always shape (2,2), and has various methods for merging two such boxes, etc, adding a point, etc. I did it that way, 'cause I had a lot of code already that simply used a (2,2) array to represent a bounding box, and I wanted all that code to still work. I have had zero problems with it. Maybe that's too trivial to be worth talking about, but this kind of use case can be handy. It is a bit awkward to write the code, though -- it would be nice to have a cleaner API for this sort of subclassing (not that I have any idea how to do that) The main problem with subclassing for numpy.ndarray is that it guarantees
too much: a large set of operations/methods along with a specific memory layout exposed as part of its public API.
This is a big deal -- we really have two concepts here: - a Python class (type) with certain behaviors in Python code - a wrapper around a strided memory block. maybe it's possible to be clear about that distinction: "Duck Arrays" are the Python API Maybe a C-API object would be useful, that shares the memory layout, but could have completely different functionality at the Python level. - CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov