On Nov 4, 2012, at 1:31 PM, Ralf Gommers wrote:
On Wed, Oct 31, 2012 at 1:05 PM, Charles R Harris charlesr.harris@gmail.com wrote:
On Tue, Oct 30, 2012 at 9:26 PM, Travis Oliphant travis@continuum.io wrote: The NPY_CHAR is not a "real type". There are no type-coercion functions attached to it nor ufuncs nor a full dtype object. However, it is used to mimic old Numeric character arrays (especially for copying a string).
It should have been deprecated before changing the ABI. I don't think it was realized that it was part of the ABI (mostly for older codes that depended on Numeric). I think it was just another oversight that inserting type-codes changes this part of the ABI.
The positive side is that It's a small part of the ABI and not many codes should depend on it. At this point, I'm not sure what can be done, except to document that NPY_CHAR has been deprecated in 1.7.0 and remove it in 1.8.0 to avoid future ABI difficulties.
The short answer, is that codes that use NPY_CHAR must be recompiled to be compatible with 1.6.0.
IIRC, it was proposed to remove it at one point, but the STScI folks wanted to keep it because their software depended on it.
I can't find that discussion in the list archives. If you know who from STScI to ask about this, can you do so?
Is replacing NPY_CHAR with NPY_STRING supposed to just work?
No, it's a little more complicated than that, but not too much. Code that uses the NPY_CHAR type can be changed fairly easily to use the NPY_STRING type, but it does take some re-writing. The NPY_CHAR field was added so that code written for Numeric (like ScientificPython's netcdf reader) would continue to "just work" with no changes and behave similarly to how it behaved with Numeric's character type.
Unfortunately, adding it to the end of the TYPE list does prevent adding any more types without breaking at least this part of the ABI.
-Travis