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 was useful.

--tom

On 6/13/07, Travis Oliphant oliphant@ee.byu.edu 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

o.key

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).

-Travis

---

Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion