Travis Oliphant <oliphant@ee.byu.edu>:
[snip]
Let me finish this example:
Suppose you have a complex short int array with
__array_descr__ = [('real','i2'),('imag','i2')]
you could describe this as
__array_typestr__ = 'V4'
Sure -- I can see how using 'V' makes sense... You're just telling the host program how many bytes you've got, and that's it. That makes sense to me. What I wondered about was what happened when you use a more specific (and conflicting) type for the typestr...
or think of it as a 4 byte integer if you want to make sure that another array package that may not support void pointers can still manipulate the data, and so the creator of the complex short int array may decide that
__array_typestr__ = 'i4'
This is basically what I'm wondering about. It would make sense (to me) to say that the data type was 'V4', because that's simply less specific, in a way. But saying 'i4' is just as specific as the complex example, above -- but it means something else! You're basically giving the program permission to interpret a four-byte complex number as a four-byte integer, aren't you? Sounds almost like a recipe for disaster to me :} On the other hand -- there is no complex integer type in the interface, and using 'c4' probably would be completely wrong as well. I would almost be tempted to say that if __array_descr__ is in use, __array_typestr__ *has* to use the 'V' type. (Or, one could make some more complicated rules, perhaps, in order to allow other types.) As for not supporting the 'V' type -- would that really be considered a conforming implementation? According to the spec, "Objects wishing to support an N-dimensional array in application code should look for these attributes and use the information provided appropriately". The typestr is required, so... Perhaps the spec should be explicit about the shoulds/musts/mays of the specific typecodes? What must be supported, what may be supported etc.? Or perhaps that doesn't make sense? It just seems almost too bad that one package would have to know what another package supports in order to formulate its own typestr... It sort of throws part of the interoperability out the window.
is the right thing to do for packages that ignore the __array_descr__ attribute.
-Travis
-- Magnus Lie Hetland Fall seven times, stand up eight http://hetland.org [Japanese proverb]