On Thu, 2003-09-25 at 12:28, Paul Dubois wrote:

I have not followed this thread in any detail but I continue to be puzzled by the idea of subclassing numarray arrays. Any subclass worth its salt has an unpredictable constructor argument list, so that virtually every ufunc and every array method have to be overridden in order to return the subclass object rather than a numarray.

I think there is a need to effectively subclass numarray where the parameter lists don't change. Doing a Matrix subclass sounds reasonable to me and we should explore the OOP necessary to make it convenient. STSCI hasn't asked for it, but a couple different numarray contributors have.

I gather that the defers-to-me stuff allows the subclass to get control of a mixed operation but that was possible with the radd, etc. operators already as in the old MA.

radd does not work for numarray + MA. Instead, the expression is resolved as numarray.__add__(MA). Were MA a numarray subclass, it would work, given the facilities provided by Python alone.

The defers-to-me-stuff is a simple work around to avoid having to reverse engineer this one Numeric behavior.

This reasoning led me to believe that subclassing had virtually no value and to the design of MA that has-a numeric array rather than is-a.

Since we want to port MA as-is to numarray, we're not changing that.

Is there some big breakthrough here I missed?

No, but there are two issues: (1) effectively supporting subclasses (2) effectively supporting interoperability with other classes.

(1) needs more discussion. (2) is already solved.