Todd Miller had some further comments that I thought were worth posting as well (and I think he makes some very good points). ************************************************************************ My [i.e. Todd's] thoughts about it:
Maybe I'm becoming a bit tedious with this, but if you look at:
No. It shows you're thinking about it carefully. Having looked at all of the examples below, I have some comments: 1. The sparseness and obscurity of the typecode "wordspace" are both demonstrated here. There are so few letters to choose from, they're often already used in some other context. Even given the large number of unused letters, it's often difficult to choose good ones and to remember what has been chosen. I think this is one of the reasons Perry chose to replace typecodes with true type objects which have rich, regular, and predictable symbolic names. 2. Typecodes were added as a backwards compatability feature of numarray, and I think it's probable that numarray beat Numeric to supporting most of these types, because otherwise they'd have been copied directly and there would be no problem. I'm not really trying to play a blame-game here, 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) 3. STSCI has layered other software on top of numarray and recarray which astronomers use to do work. It is the friction of that interface which makes correcting these consistency problems more difficult than might be immediately apparent.
I think it's important to agree with a definitive set of charcodes and use them uniformly throughout numarray.
I wish this were possible, but I'm thinking we should try to find an alternative approach altogether, one which may be more verbose but implicitly free of conflict. A means for specifying a recarray format might be created from tuples, type objects, and integer repetition factors. The verbosity of this approach might be a litte tedious, but it would also be transparent, maintainable, and conflict free. I think we should add an "obsolescent feature" warning to numarray and recarray which flags any use of character typecodes when the appropriate command line switches are set.
Suggestion: if recarray charcodes are not necessary to match the Numeric ones, I propose that using the Python convention maybe a good idea. Look at the table in: http://www.python.org/doc/current/lib/module-struct.html.
This sounds good to me, except that it will break an existing interface that I don't have control over. Therefore, I suggest we correct the problem by coming up with something better.