[Numpy-discussion] problem with ndarray attributes

[Travis Oliphant]

Christopher Hanley wrote:

> Hi Travis,
>
> I have run across a feature in numpy which I am not sure how to 
> handle.  One of the new features of the ndarray is that named fields 
> can be accessed as attributes.  So, if a user created a recarray with 
> fields named "address", "phone", and "names" they would be able to 
> access all of the names in the recarray objects with 
> "recarrayObject.names".


To be clear.  This is only true for a recarray subclass.  Standard 
ndarray's cannot look-up fields with attribute access.

>
> I have found that this can cause problems when a user creates a table 
> with a field name that happen to coincide with an existing class 
> attribute or method.  In particular, I am having a problem in pyfits 
> where a user has a table with a column named "field".  This column 
> name is causing an attribute "field" to be created that overrides the 
> existing class field method.


This is a standard problem with using attribute access.   I suppose it 
would be better to always lookup the attributes first on the object and 
then if that fails use field access.  That way library code would not 
break if a user happened to name their fields after a method or 
property.   Users would have to change code if new methods or properties 
were added (although that won't be as common). 

>
> It would seem to me that existing class methods and attributes should 
> take precedence over the attributes created to correspond to column 
> names.  Is there a way to implement this behavior in ndarray?


I think this is the right thing to do.   Are there any objections?

-Travis