
Paul Dubois writes:
Every time the subject of subclassing a numeric array comes up, it as if nobody ever thought of it before. Been there, done that. It doesn't turn out to be all that useful. To see why, consider a + b where a and b are Foo instances, and Foo inherits from numarray.
a. a + b will be a numarray, not a Foo instance, unless you write a new + operator. b. Attempting to have numarray itself apply a subclass constructor to the result runs into the problem that numarray does not have any idea what the constructor's signature is or what information is needed to fill out that constructor. c. Even if the subclass accepts numarray's constructor signature, it would rarely produced satisfactory results just "losing" the Foo'ness details of a and b.
This same argument applies to every method that returns a Foo instance, and every ufunc. So you end up redoing everything anyway.
In short, worrying about subclassing is way down the list of things we ought to consider.
Paul illustrates some important points. While I'm not as down on the ability to subclass (more on that later), he is absolutely right that most think that subclassing is a breeze and don't realize that it is far from being so. The arguments for this would be helped immensely by a practical example of a desired subclass. This does far more to illustrate the issues than an abstract discussion. For most instances that I have considered or thought about it is unavoidable that one must override virtually all (if not all) the operators and functions. Nevertheless, subclassing can still save a great deal of work over implementing a completely new extension. But you'll have to deal with defining how all the operators and functions should behave. In our view, the most valuable subclassing in numarray comes from subclassing NDArray, which handles all the structural operations for arrays (recarray makes heavy use of this). But recarrays don't try to support numerical operations, and that makes it fairly easy. Subclassing numarrays is significantly more work for the reasons cited. Perry