[Numpy-discussion] Re: Numeric3 PEP

[Travis Oliphant]

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

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 
type-specific needs. 

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

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

-Travis