In article <[EMAIL PROTECTED]>, Pierre GM <[EMAIL PROTECTED]> 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 exception. 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 buried. 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 this. 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. Michael. ------------------------------------------------------------------------- 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 http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
