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