[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