[Numpy-discussion] Re: [Python-Dev] Re: Numeric life as I see it

[Travis Oliphant]

>[Travis]
>  
>
>>I appreciate some of what Paul is saying here, but I'm not fully
>>convinced that this is still true with Python 2.2 and up new-style
>>c-types.   The concerns seem to be over the fact that you have to
>>re-implement everything in the sub-class because the base-class will
>>always return one of its objects instead of a sub-class object.
>>It seems to me, however,  that if the C methods use the object type
>>alloc function when creating new objects then some of this problem is
>>avoided (i.e. if the method is called with a sub-class type passed in,
>>then a sub-class type gets set).
>>    
>>
>
>This would severely constrain the __new__ method of the subclass.
>  
>
I obviously don't understand the intricacies here, so fortunately it's 
not a key issue for me because I'm not betting the farm on being able to 
inherit from the arrayobject.  But, it is apparent that I don't 
understand all the issues.

>>Have you looked at how Python now allows sub-classing in C?  I'm not an
>>expert here, but it seems like a lot of the problems you were discussing
>>have been ameliorated.  There are probably still issues, but....
>>
>>I will know more when I seen what happens with a Matrix Object
>>inheriting from a Python C-array object.
>>    
>>
>
>And why would a Matrix need to inherit from a C-array? Wouldn't it
>make more sense from an OO POV for the Matrix to *have* a C-array
>without *being* one?
>  
>
The only reason I'm thinking of here is to have it inherit from the 
C-array many of the default methods without having to implement them all 
itself.   I think Paul is saying that this never works with C-types like 
arrays, and I guess from your comments you agree with him.

The only real reason for wanting to construct a separate Matrix object 
is the need to overload the * operation to do matrix multiplication 
instead of element-by-element multiplication. 

-Travis