On Thu, Jul 6, 2017 at 4:42 AM, Ben Rowland <bennyrowland@mac.com> wrote:

Slightly off topic, but as someone who has just spent a fair amount of time implementing various
subclasses of nd-array, I am interested (and a little concerned), that the consensus is not to use
them. Is there anything available which explains why this is the case and what the alternatives
are?

Writing such docs (especially to explain how to write array-like objects that aren't subclasses) would be another good topic for the sprint ;).

But more seriously: numpy.ndarray subclasses are supported, but inherently error prone, because we don't have a well defined subclassing API. As Martin will attest, this means seemingly harmless internal refactoring in NumPy has a tendency to break downstream subclasses, which often unintentionally end up relying on untested implementation details.

This is particularly problematic when subclasses are implemented in a different code-base, as is the case for user subclasses of numpy.ndarray. Due to diligent testing efforts, we often (but not always) catch these issues before making a release, but the process is inherently error prone. Writing NumPy functionality in a manner that is robust to all possible subclassing approaches turns out to be very difficult (nearly impossible).

This is actually a classic OOP problem, e.g., see https://en.wikipedia.org/wiki/Composition_over_inheritance