FW: [Numpy-discussion] typecodes in numarray

[Perry G. <pe...@st...>]

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.