[Numpy-discussion] problem with ndarray attributes

[Colin J. Williams]

Travis Oliphant wrote:

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

Is any consideration being given to integrating recarray into ndarray?  
It seems to me that attribute access is desirable, providing that there 
is some check to ensure that the name does not duplicate an existing 
attribute.

Colin W.

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