[PYTHON MATRIX-SIG] Finalized 0.3 interface (hopefully)
Jim Fulton, U.S. Geological Survey
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
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,
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: firstname.lastname@example.org
administrivia to: email@example.com