Re: [Numpy-discussion] Re: [Python-Dev] Re: Numeric life as I see it
On 10.02.2005, at 05:36, Guido van Rossum wrote: 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? Definitely. Most array operations make no sense on matrices. And matrices are limited to two dimensions. Making Matrix a subclass of Array would be inheritance for implementation while removing 90% of the interface. On the other hand, a Matrix object is perfectly defined by its behaviour and independent of its implementation. One could perfectly well implement one using Python lists or dictionaries, even though that would be pointless from a performance point of view. Konrad. -- --- Konrad Hinsen Laboratoire Leon Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: [EMAIL PROTECTED] --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Numpy-discussion] Re: [Python-Dev] Re: Numeric life as I see it
On Wed, 09 Feb 2005 22:02:11 -0700, Travis Oliphant <[EMAIL PROTECTED]> wrote: GvR: >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? Travis: > 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. This is dredging stuff up from years (and layers and layers of new memories =), but I think that what Paul was referring to was in fact independent of implementation language. The basic problem, IIRC, had to do with the classic (it turns out) problem of confusing the need for reuse of implementation bits with interface inheritance. We always felt that things that people felt were "array-like" (Matrices, missing value arrays, etc.) _should_ inherit from array, and that (much like you're saying), it would save work. In practice, however, there were a few problems (again, from lousy memory), all boiling down to the fact that the array object implemenation implies interfaces that weren't actually applicable to the others. The biggest problems had to do with the fact that when you do subclassing, you end up in a nasty combinatorial problem when you wanted to figure out what operand1 operator operand2 means, if operand1 is a derivative and operand2 is a different derivative. In other words, if you multiply a matrix with a missingvalues array, what should you do? Having a common inheritance means you need to _stop_ default behaviors from happening, to avoid meaningless results. It gets worse with function calls that take "array-like objects" as arguments. A lot of this may be resolvable with the recent notions of adaptation and more formalized interfaces. In the meantime, I would, like Paul, recommend that you separate the interface-bound type aspects (which is what Python classes are in fact!) from the implementation sharing. This may be obvious to everyone, and if so, sorry. --david ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Numpy-discussion] Re: [Python-Dev] Re: Numeric life as I see it
[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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
