problem with ndarray attributes
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". 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. 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? Thank you for your time and help, Chris
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
On Mar 27, 2006, at 5:02 PM, Travis Oliphant wrote:
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).
I think some mechanism must be built in to make it easy to add new attributes and methods (e.g., some method to append new object attributes that are protected?). That way subclassing record arrays wouldn't have to do their own checks on this but rather register their new methods and attributes as things that would not get overridden (or is there some more magic way of doing this that doesn't require something this explicit?)
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?
Seems like the obvious thing. Otherwise any tool one builds that allows a user to use arbitrary field names can suddenly break if a user uses the wrong name. With the proposed change, there is always the field method to get around any name collisions. Perry
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
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".
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.
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?
Now that I've written that I think the class methods and attributes should come first, I should mention, however, that a library writer could write ndarray.__getattribute__(a,'field')(*args) to make sure that the method a.field(*args) always gets called. This seems like quite a burden to force on library writers, though. I'd rather have users be aware of what they are using as field names since the methods and attributes on arrays should not be changing excessively. -Travis
participants (4)
-
Christopher Hanley -
Colin J. Williams -
Perry Greenfield -
Travis Oliphant