Paul F Dubois wrote:
I don't understand this remark:
<snip >but I am making an argument that perhaps
numarray should only go so far in the support of what I regard as an obsolescent feature. If the Numeric developers choose to continue extending the use of typecodes in ways that are incompatible with numarray, one way of dealing with it is to "just say no". We are going beyond the scope of backwards compatability to on-going compatabilty. (Which we may still have to do but needs to be discussed and considered)
There is no "on-going" Numeric development. It stops the minute numarray is ready. Period. We developers all agreed on that. The whole reason for numarray is that Numeric was pronounced unmaintainable and unextendable by those who frequently had to work on it. To do anything else will fragment the entire numerical python community and software set.
Thanks for clarifying Paul. My point didn't quite come out right. A better way to put it might have been: 1. Numarray and Numeric are subject to accidental divergence. As long as they both continue to change concurrently, they will probably differ even in interface. Because numarray isn't quite ready yet, they are both still changing. 2. Typecodes in particular are something numarray is superceding with something better. Because of this, providing on-going compatability with Numeric typecodes may not make sense. 3. Numeric compatability is not the only driver for the choice of recarray typecodes so I can't make arbitrary changes without affecting other software and people. 4. I think there's a clearer, numarray type object based approach to describing recarray formats which does not use typecodes at all. Thus, instead of attampting to weed through and unify layers of conflicting type codes, we might be able to end-run the whole problem with an alternative approach. Todd
------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
--Boundary_(ID_V53Q9uhCvVN46XJvLKOLLw)--