[Numpy-discussion] attribute names on record arrays
Fri Jun 15 11:30:12 CDT 2007
One thing I've done in situations like this where you want names of
dynamic fields to be available for tab completion but the object has
other methods and instance variables that might conflict is to use a
proxy object that just contains the fields. So for instance you have
a property called F that returns an object whose attributes are the
fields of the rec array, in this case. Then the api for a rec array
with fields "field1" and "field2" simply becomes recArr.F.field1 or
recArr.F.field2. In my opinion it partitions the namespaces nicely,
avoiding the name collision problems entirely. Because it is a
property, it puts off the cost of initializition till you use it,
saving those who do not from incurring any cost Finally it works very
nicely in ipython because when you type recArr.F. And then tab
complete you get only recArray fields, whereas if you type recArr. And
then tab complete you get only.the object attributes.
There may be other issues I'm not considering or people may not like
it, but just wanted to throw the idea out there if anyone thought it
On 6/13/07, Travis Oliphant <email@example.com> wrote:
> John Hunter wrote:
> >I fund myself using record arrays more and more, and feature missing
> >is the ability to do tab completion on attribute names in ipython,
> >presumably because you are using a dict under the hood and __getattr__
> >to resolve
> >where o is a record array and key is a field name.
> >How hard would it be to populate __dict__ with the attribute names so
> >we could tab complete on them?
> Not hard, in fact somebody suggested a patch that does exactly that.
> The only question is what impact that might have on other things. For
> example, I think we would have to make sure that the proper order for
> fields that conflict with object attributes would be (I'd have to look
> to remember what the current order is).
> Numpy-discussion mailing list
More information about the Numpy-discussion