On Fri, Jan 24, 2003 at 12:34:54PM -0800, Paul F Dubois wrote:
Every time the subject of subclassing a numeric array comes up, it as if nobody ever thought of it before.
Why do you treat me as if I was trying to sell the "Next Big Thing"!? First, I must tell you that the first time I came across the idea of subclassing Numeric arrays was while reading the "Subclassing" subsection, in the "Special Topics" section of the Numeric Python manual. Your name, Paul, appears as one of the authors. Second, subclassing Numeric arrays may be useful. Again, the distribution of Numeric Python even has one big example: making a linear algebra oriented version of Numeric python, where the operations would be the standard matrix and vector operations instead of the element-wise operations.
Been there, done that. It doesn't turn out to be all that useful.
As seen by the examples above is obvious you did. Still, I don't see how can you possibly say it isn't 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 general it may be usefully to subclass Numeric arrays if one just want to add/overload methods, but no new properties.] And third, if you read my thread you'd notice that the use of methods instead of functions has implications/benefits much beyond the subclassing issue. It's particularly important for Numeric-alike arrays. All objects in Python are virtual so you don't actually need to subclass to use different kind of objects in the same piece as code. While you're right in the sense that for many practical applications there is little use of subclassing - a sparse matrix class is one of them for instance -, you can't deny that is quite useful to have Numeric-alike arrays, in the same basis as is currently done with the file-alike objects in Python, i.e., they could be strings, web pages but as long as they define a set of methods, these.
In short, worrying about subclassing is way down the list of things we ought to consider.
If so, then why did your comment only focused on the subclassing issue? The subclassing was a mere introduction [perhaps unfortunate, I confess] to the method overloading issue. Now, if you could (re)read my first post and comment on my actual suggestion I would appreciate. Of course that I have no problems if the Numeric/numarray maintainers decide to turn it down. I'll most probably just use UserArray.py to create a "method-ized" version of Numeric, so that my algorithms can work with both Numeric array and sparse matrices. (I do have a real case need of for this.) BTW, there is an alternative to create full-methodized Numeric array: just add a attribute which points to the module which the class belongs, e.g., "myarray.module.take" would point to "Numeric.take" if it was a Numeric array, or "Sparse.take" if it was a sparse matrix. Regards, José Fonseca __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com