[Numpy-discussion] Re: Numeric3 PEP
oliphant at ee.byu.edu
Sat Feb 19 12:54:22 CST 2005
> It seems that the record type is to be handled under the VoidArray. I
> hope that it will permit the setting and reading of fields.
Exactly. A Python record class can make use of the basic array structure.
> For example, if recs is an instance of an Array of records, then it
> should be possible to write:
> >>> recs[22, 5].sex= 'F'
> >>> recs[22, 5].sex
This will need to be handled by the record class specifically (it will
make use of a void array). I do not see a need to clutter the general
array c-type with this.
Along that idea, the current design is based heavily on Numeric which
places all arraytypes under a single ArrayType. It "knows" about the
type of each array instead of asking the type what it can do. I know
numarray made strides in a different direction (but I'm not sure how far
it got, since there is still this basic set of types).
I am very willing to consider the possibility of a more top-down design
in which a basic array c-type had no information about what was in the
array (it just managed its shape, its memory usage, and the size of the
memory being used). Then, subtypes could be created which handled
This seems to be a more logical direction to pursue, but it is a bit of
a switch and so carries even more risk. Someone from numarray could
help here, perhaps.
> It is not clear, from the current draft, what is intended for
> ObjectArray. Can these be any Python objects tuple, list etc. or
> instances of any user defined class?
It is the familiar "O" type from Numeric. Yes, these objects can be any
Python object whatever. Numeric already handles this (and numarray
recently added them).
> There is also a tofile method ( I would prefer toFile), does this mean
> that pickling would be used for the object instances?
The naming convention is lowercase (camelCase is reserved for
ClassInstances). I have not thought that far, but probably...
> The term WRITABLE is used, is this different from "mutable", the term
> used by Python?
MUTABLE is a better term. Do numarray folks agree?
> "Methods such as x.r(), x.i(), and x.flatten() are proposed.". Why
> not use properties, x.r, x.i and x.flatten. The parentheses appear
The distinction is that attributes do not return copies, but methods
might. Thus, the idea is that x.i() would return zeros if the array
were not complex, but x.imag would raise and error. I like the idea of
attributes being intrinsic properties of an array, while methods could
conceivably return or do anything.
Thanks for your continued help with clarification and improvement to the
More information about the Numpy-discussion