recarray.__setattr__ bug?
Michael McNeil Forbes
mforbes at phys.washington.edu
Sat Oct 28 21:45:27 CDT 2006
In article <200610281530.22929.pgmdevlist at gmail.com>,
Pierre GM <pgmdevlist at gmail.com> 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
More information about the Numpy-discussion
mailing list