On Thu, Jul 6, 2017 at 4:42 AM, Ben Rowland <bennyrowl...@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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
