Fw: [Numpy-discussion] numarray.records - get/set item

[Sebastian H. <ha...@ms...>]

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" <pe...@st...>
To: "Sebastian Haase" <ha...@ms...>;
<num...@li...>
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