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

[Jim Fulton, U.S. Geological Survey]

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.

(snip)

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

    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.

(snip)

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

Jim


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

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