[Matrix-SIG] Numerical plans (fwd)

[Konrad Hinsen]

> Well, since I think I was the main force behind that, I'll say that the
> main idea was that I wanted to be able to continue work on the
> functionality of array objects in Python, not in C.  The C code is a mess,

It's a good idea to be able to implement functionality in Python.
But if the C code is a mess (and I certainly agree), it ought to be
cleaned up; there's no substitute for that, unfortunately.

> Instead, what Paul and I are planning to do is to revert to the old type,
> but to do UserArray *right*.  The new features that I mention above would
> then be implemented in new Python classes, which would use array objects
> as member data (I mean, instance attributes).  

But any attempt to implement significant functionality in Python
will lead to the same problem: Most users will end up using some
Python object, which C modules won't accept as an array.

My personal convention in MMTK is that all high-level "array-like"
object have an attribute "array" that stores the array object.
C modules then check for an array, and if the type check fails they
get the attribute "array" and continue with that. Maybe something
similar would be a good convention in general.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------