[Numpy-discussion] RecArray.tolist() suggestion

Russell E Owen rowen at u.washington.edu
Mon Jul 12 16:09:00 EDT 2004


At 5:14 PM -0400 2004-07-12, Perry Greenfield wrote:
>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)?

In my opinion, an single item of a record array should be a 
RecordItem object that is a dictionary that keeps items in field 
order. Thus:
- use the standard dictionary interface to deal with values by name 
(except the keys are always in the correct order.
- one can also get and set the all data at once as a tuple. This is 
NOT a standard dictionary interface, but is essential. Functions such 
as getvalues(), setvalues(dataTuple) should do it.

Adopting the full dictionary interface means one gets a standard, 
mature and fairly complete set of features. ALSO a RecordItem object 
can then be used wherever a dictionary object is needed.

I suspect it's also useful to have named field access:
RecordItem.fieldname
but am a bit reluctant to suggest so many different ways of getting 
to the data.

I assume it will continue to be easy to get all data for a field by 
naming the appropriate field. That's a really nice feature. It would 
be even better if a masked array could be used, but I have no idea 
how hard this would be.


Which brings up a side issue: any hope of integrating masked arrays 
into numarray, such that they could be used wherever a numarray array 
could be used? Areas that I particularly find myself needing them 
including nd_image filtering and writing C extensions.

-- Russell

P.S. I submitted several feature requests and bug reports for records 
on sourceforge months ago. I hope they'll not be overlooked during 
the review process.




More information about the NumPy-Discussion mailing list