[Numpy-discussion] Re: [Python-Dev] Re: Numeric life as I see it
oliphant at ee.byu.edu
Thu Feb 10 06:02:11 CET 2005
>>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.
More information about the Python-Dev