Paul Dubois wrote:
My intention was to replace Numeric with a quickly-written better implementation. That is why the Numeric page says what it says. I've left it that way as a reminder of the goal, which I continue to believe is important. Besides cleaning it up, the other motivation was to back off the 'performance at all cost' design enough that we would be 'safe' enough to qualify for the Python distribution and become a standard module. Numeric was written without many safety checks *on purpose*. Over time opinions about that philosphy changed.
In fact, the team that wrote numarray did not do what I asked for, leading to the present confusion but also to, as noted by Altet, some nice features. I think it was unfortunate that this happened but as with most open source projects the person doing the work does the work the way they want and partly to satisfy their own needs. But they do the work, all credit to them. I'm not complaining.
Just to clarify, if we could have found a way of doing a basic version and layering on the extra features we would have. To take a specific example, if you want to be able to access data in a buffer that is spaced by intervals not a multiple of the data element size (which is what recarray needs to do) then one needs to handle non-aligned data in the basic version (otherwise segfaults will happen). I couldn't see a way of handling such arrays without the mechanism for handling non-aligned data being built into the basic mechanism (if someone else can, I'd like to see it). So it's a good design approach, but sometimes things can't work that way. Perry