Hi All, I doubt I'm really the last one thinking ndarray subclassing is a good idea, but as that was stated, I feel I should at least pipe in. It seems to me there is both a perceived problem -- with the two subclasses that numpy provides -- `matrix` and `MaskedArray` -- both being problematic in ways that seem to me to have very little to do with subclassing being a bad idea, and a real one following from the fact that numpy was written at a time when python's inheritance system was not as well developed as it is now.
Though based on my experience with Quantity, I'd also argue that the more annoying problems are not so much with `ndarray` itself, but rather with the helper functions. Ufuncs were not so bad -- they really just needed a better override mechanism, which __array_ufunc__ now provides -- but for quite a few of the other functions subclassing was clearly an afterthought. Indeed, `MaskedArray` provides a nice example of this, with its many special `np.ma.<function>` routines, providing huge duplication and thus lots of duplicated bugs (which Eric has been patiently fixing...). Indeed, `MaskedArray` is also a much better example than ndarrat of a class that is really hard to subclass (even though, conceptually, it should be a far easier one). All that said, duck-type arrays make a lot of sense, and e.g. the slicing and shaping methods are easily emulated, especially if one's underlying data are stored in `ndarray`. For astropy's version of a relevant mixin, see http://docs.astropy.org/en/stable/api/astropy.utils.misc.ShapedLikeNDArray.html All the best, Marten _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion