recarray.__setattr__ bug?

Michael McNeil Forbes mforbes at
Sat Oct 28 21:45:27 CDT 2006

In article <200610281530.22929.pgmdevlist at>,
 Pierre GM <pgmdevlist at> wrote:
> So that I could have a field named 'shape', and modifying 
> r.shape would change the shape of the array, not the content of the field ?
> That makes sense, but isn't it a bit dangerous ? Shouldn't we have a list of 
> reserved keywords (dtype, shape...) that would raise an exception if used as 
> field names ?

Since the field names can be used with regular arrays without any 
consequences, I think it would be bad to raise an exception with 
recarrays where there was no problem with regular arrays, and regular 
arrays should allow field names such as 'shape'.

A note should be added to the recarray documentation, however, pointing 
out this pitfall.  Perhaps a warning could be raised when a recarray is 
constructed with poor fieldname choices, but I would not raise an 

In any case, I think is is dangerous to allow the fieldnames to hide 
standard array members.  This would break the array interface for such 
recarrays causing many subtle problems for any algorithm that assumed 
the recarray to behave as a standard array: This code could be deeply 

Instead, the user's code would behave 'strangely', but it is also the 
user's code that assigned bad fieldnames, and a warning would alert of 

Another concern that I found with the recarray interface is that the 
current implementation exhibits quite poor performance, but I am not 
sure how to fix this yet.

Is there any documentation about the general design decisions behind 
recarrays?  I think they could be very useful for simplifying code, but 
could use several improvements.


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo

More information about the Numpy-discussion mailing list