Re: [Numpy-discussion] Array interface
--- Magnus Lie Hetland
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.)
Yup, having multiple ways to spell the same information will likely cause problems. Wouldn't be bad for the protocol to say "thou shalt use the specfic typestr when possible". Or to say that the __array_descr__ is only for 'V' typestrs.
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...
I think the intent is that libraries like wxPython or PIL can recognize data that they *want* to work with. They can raise an exception when passed anything that is more complicated than they're willing to deal with. I think many packages will simply punt when they see a 'V' typestr and not look at the more complicated description at all. Nothing wrong with that... The packages that produce more complicated data structures have a way to express it and pass it to the packages that are capable of consuming it. Easy things are easy, and hard things are possible.
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.
Being very precise in the language describing the protocol is probably a good thing, but I don't see anything that requires packages to formulate their typestr's differently. The little bit of ambiguity that is in the __array_typestr__ and __array_descr__ attributes can be easily clarified. Cheers, -Scott
Scott Gilbert
[snip]
I think the intent is that libraries like wxPython or PIL can recognize data that they *want* to work with. They can raise an exception when passed anything that is more complicated than they're willing to deal with.
Sure. I'm just saying that it would be good to have a baseline -- a basic, mandatory level of conformance, so that if I expose an array using only that part of the API (or, with the rest being optional information) I know that any conforming array consumer will understand me. As long as we have this, I have to know the capabilities of my consumer before I can write an appropriate typestr, for example. E.g., one application may only accept b1, while another would only accept i1 etc. Who knows -- there may well be sets of consumer applications that have mutually exclusive sets of accepted typestrings unless a minimum is mandated. That's really what I was after here. In addition to saying that typestr *must* be supported, one might say something about what typestrs must be supported. On the other hand -- perhaps such requirements should only be made on the array side? What requirements can/should one really make on the consumer side? I mean -- even though we have a strict sequence protocol, there is nothing wrong with creating something sequence-like (e.g., supporting floats as indices) and having consumer functions that aren't as strict as the official protocol... I just think it's something that it might be worth being explicit about. -- Magnus Lie Hetland Fall seven times, stand up eight http://hetland.org [Japanese proverb]
participants (2)
-
Magnus Lie Hetland
-
Scott Gilbert