[Numpy-discussion] RecArray.tolist() suggestion

[Perry Greenfield]

Francesc Alted wrote:
> 
> As Perry said not too long ago that numarray crew would ask for 
> suggestions
> for RecArray improvements, I'm going to suggest a couple.
> 
> I find quite inconvenient the .tolist() method when applied to RecArray
> objects as it is now:
> 
> >>> r[2:4]
> array(
> [(3, 33.0, 'c'),
> (4, 44.0, 'd')],
> formats=['1UInt8', '1Float32', '1a1'],
> shape=2,
> names=['c1', 'c2', 'c3'])
> >>> r[2:4].tolist()
> [<numarray.records.Record instance at 0x406a946c>, 
> <numarray.records.Record instance at 0x406a912c>]
> 
> 
> The suggested behaviour would be:
> 
> >>> r[2:4].tolist()
> [(3, 33.0, 'c'),(4, 44.0, 'd')]
> 
> Another thing is that an element of recarray would be returned as a tuple
> instead as a records.Record object:
> 
> >>> r[2]
> <numarray.records.Record instance at 0x4064074c>
> 
> The suggested behaviour would be:
> 
> >>> r[2]
> (3, 33.0, 'c')
> 
> I think the latter would be consistent with the convention that a
> __getitem__(int) of a NumArray object returns a python type instead of a
> rank-0 array. In the same way, a __getitem__(int) of a RecArray should
> return a a python type (a tuple in this case).
> 
These are good examples of where improvements are needed (we are 
also looking at how best to handle multidimensional arrays and
should have a proposal this week).

What I'm wondering about is what a single element of a record array
should be. Returning a tuple has an undeniable simplicity to it.
On the other hand, we've been using recarrays that allow naming the
various columns (which we refer to as "fields").  If one can refer
to fields of a recarray, shouldn't one be able to refer to a field
(by name) of one of it's elements? Or are you proposing that basic
recarrays not have that sort of capability (something added by a
subclass)?

Perry