My situation where I got onto this, is having one field named 'mmm'
("MinMaxMean") being an 3 element array.
Now, to assign the values first I tried:
self.hdrArray = makeHdrArray(self.h) #this makes the record array
self.hdr = self.hdrArray[0].field #this is my shortcut to the
bound member function
# it essentially is a solution (hack) for the getitem part
# but regarding setitem I had to learn that "assigning to a function" is
illigal in Python - as opposed to C++
#so to do assignment I need to do:
self.hdr('mmm')[0], self.hdr('mmm')[1], self.hdr('mmm')[2] = (mi,ma,av)
now that I'm looking at it,
self.hdrArray[0].setfield('mmm', (mi,ma,av))
would probably be better...
How about adding an attribute 'f' which could serve as a "proxy" to allow:
myRec.f.mmm = (mi,ma,av)
and maybe even additionally:
myRec.f['mmm'] = (mi,ma,av)
Regards,
Sebastian
----- Original Message -----
From: "Perry Greenfield" <perry(a)stsci.edu>
To: "Sebastian Haase" <haase(a)msg.ucsf.edu>;
<numpy-discussion(a)lists.sourceforge.net>
Sent: Thursday, December 04, 2003 3:08 PM
Subject: RE: [Numpy-discussion] numarray.records - get/set item
> > Hi,
> > Is it maybe a good idea to add this to the definition of 'class Record'
> >
> > class Record:
> > """Class for one single row."""
> > <snip>
> > def __getitem__(self, fieldName):
> > return self.array.field(fieldName)[self.row]
> > def __setitem__(self, fieldName, value):
> > self.array.field(fieldName)[self.row] = value
> >
> > I don't know about the implications if __delitem __ and so on are not
> > defined.
> > I just think it would look quite nice to say
> > myRecArr[0]['mmm'] = 'hallo'
> > as opposed to
> > myRecArr[0].setfield('mmm', 'hallo')
> >
> > Actually I would even like
> > myRecArr[0].mmm = 'hallo'
> >
> > This should be possible by defining __setattr__.
> > It would obviously only work for fieldnames that do not contain '.' or '
'
> > or ...
> >
> > Any comments ?
> >
> >
> We've had many internal discussions about doing this. The latter was
> considered a problem because of possible name collisions of field
> names with other attributes or methods. The former is not bothered
> by this problem, but we decided to be conservative on this and see
> how strong the need was. We are interested in other opinions.
>
> Perry