[PYTHON MATRIX-SIG] Finalized 0.3 interface (hopefully)

[James Hugunin]

   From: "Jim Fulton, U.S. Geological Survey" <jfulton@usgs.gov>

   > The two special data members "__array__", and "__return_constructor__"
   > will be supported for python objects that want to pretend to be an
   > array.

   After thinking about this a bit, I'm quite comformable with the
   __array__ member idea, because there is a precedent with __float__,
   __int__, and __long__.  However, I have a *strong* opinion that
   __array__ should be a member *function* that returns an instance as an
   array.  This is in keeping with __float__, __long__, etc.  If a
   user-defined type wants to store it's data in an array data member and
   return the member, it can, but other user-defined classes may want to
   compute and return array data on demand.

This makes sense.

   I would also recomment that the __array__ member function should have
   an optional type code argument so that an extension that wants, say, a
   double precision array can request one.

I don't agree with this.  I really think that the __array__ member
function should return whatever the internal array is used by the
object, and let the extension convert it as it sees fit. 

   With an __array__ member function, I could, for example, immagine database
   table objects that extracted their numeric data as an array on demand.
   This could be quite useful.

This sounds useful.

   I'm not so comfortable with the __return_constructor__ idea.  It seems
   to only make sense for single-argument functions.  I have an alternate
   proposal.  Suppose that certain functions allowed an optional
   (keyword?) argument that provided this constructor.  So, for example,
   instead of:

       bar=sin(foo)

   where bar and foo are both Spams (e.g. Arrays) you would have:

       bar=sin(foo,Spam)

   Now, you don't want to have to type ",Spam" everytime, not because you
   don't like typing, but because you don't want the clutter, so you
   define a "sin" method in Spam:

       def sin(self): return sin(self,self.class)

   so then you could do:

       bar=foo.sin()

   I realize that this is not quite as pretty as the first version (or is
   it?), but it feels cleaner overall to me.  In the case of
   multi-parameter functions, it will be clear which object (the
   reciever of the message) determines the return type.

This is actually the version that I currently have running (more or
less) it can infact be implemented entirely in python as a wrapper
around the underlying math functions.  My principle problem with this
approach is that it requires me to know about all of the available
numeric functions and define equivalents for them whenever I define a
new Spam.  This just seems unreasonable to me.

For example, let's say I make a OneIndexArray (FORTRAN style indexes
start at 1).  Obviously, I want this array to work with all of the
existing operations on arrays, and to return a OneIndexArray back.

I think that Jim F sees a problem with 

power(OneIndexArray, Matrix).

I would simply have this function call raise an exception saying that
it was called with arrays having different __return_constructor__'s.


   > One last question on installation:
   >
   > I plan to package this up as an addition to the standard python
   > distribution, therefore, installation will consist of adding files to
   > Modules, Lib, and Include.  Does this strike anybody as an
   > unreasonable thing to do?

   For now, it's OK, but the released version should be a stand-alone module.

Maybe I'll let somebody else take care of these final packaging details.

   Jim

-Jim



=================
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================