[PYTHON MATRIX-SIG] Finalized 0.3 interface (hopefully)
Fri, 19 Jan 96 11:39:18 EST
From: "Jim Fulton, U.S. Geological Survey" <email@example.com>
> 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.
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,
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.
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
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.
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: firstname.lastname@example.org
administrivia to: email@example.com