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

Jim Fulton, U.S. Geological Survey jfulton@usgs.gov
Fri, 19 Jan 1996 11:17:33 -0500

On Jan 19, 10:43am, James Hugunin wrote:
> Subject: [PYTHON MATRIX-SIG] Finalized 0.3 interface (hopefully)
> Well, the comments on my previous post seem to have fallen off, so
> I'll try to summarize again and see if everybody's more or less happy.


> 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.

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.

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.

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:


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


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:


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.


> 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.


MATRIX-SIG  - SIG on Matrix Math for Python

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