[Numpy-discussion] recarray field names
esheldon at kicp.uchicago.edu
Sun Jul 9 09:55:36 CDT 2006
Hi everyone -
(sigh) These gmail issues are really annoying...so I apologize
if the gmail version of this message shows up in a few days.
I brought up the issue a while back of having a simple way to
access the field names of an array. The quick summary: accessing
field names has some oddness that needs cleaning up.
The argument that this is important isn't too hard to make:
most astronomers work with lists of objects with a slew of
properties and these are most naturally stored in a recarray.
We use generic file formats like FITS that don't require the
user to know what is in the file ahead of time, but once the
data is read this information should be easily accessible, both
interactively and in code. I'm sure similar arguments can be
made for other users.
On 3/15/06, Travis Oliphant <oliphant at ee.byu.edu> wrote:
- Hide quoted text -
> Fernando Perez wrote:
> > Mmh, just curious: I wonder about the wisdom of that overloading of a
> > 'magic' key (-1). It will make thinks like
> > for name in t.dtype.fields:
> No real wisdom. More organic growth. Intially I didn't have an ordered
> list of fields, but as more complicated data-type descriptors were
> supported, this became an important thing to have. I should have
> probably added a n additional element to the PyArray_Descr structure.
> Remember, it was growing out of the old PyArray_Descr already and I was
> a little concerned about changing it too much (there are ramifications
> of changing this structure in several places).
> So, instead of adding a "ordered_names" tuple to the dtype object, I
> just stuck it in the fields dictionary. I agree it's kind of odd
> sitting there.
> It probably deserves a re-factoring and pulling that out into a new
> attribute of the dtype object.
> This would mean that the PyArray_Descr structure would need a new object
> (names perhaps), and it would need to be tracked.
> Not a huge change and probably worth it before the next release.
More information about the Numpy-discussion