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.

-Travis






On Oct 30, 2012, at 8:46 PM, Charles R Harris wrote:



On Tue, Oct 30, 2012 at 4:08 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
Hi,

Ticket 2228 says ABI was broken in 1.6.x. Specifically, NPY_CHAR in the NPY_TYPES enum seems to be have been moved. Can anyone comment on why the 3 datetime related values were inserted instead of appended?

I don't know, although having NPY_CHAR after  NPY_NTYPES goes back to 1.0.3


                    NPY_NTYPES,
                    NPY_NOTYPE,


                    NPY_CHAR,      /* special flag */
And I expect it was desired to keep it there on the expectation that there was a reason for it. The decision not to append was in 1.4.0

                    NPY_DATETIME, NPY_TIMEDELTA,
                    NPY_NTYPES,
                    NPY_NOTYPE,
                    NPY_CHAR, /* special flag */

And probably due to Robert Kern or Travis, IIRC who worked on getting it in.

I don't see a good way to get around the ABI break, I think the question going forward needs to be whether we leave it after NPY_NTYPES or make it part of the unchanging ABI, and I suspect we need to know what the 'special flag' comment means before we can make that decision. My suspicion is that it wasn't considered a real numeric type, but rather a flag marking a special string type, in which case it probably doesn't really belong among the types, which I think is also indicated by NPY_NOTYPE. Moving NPY_CHAR could have implications we would want to check, but I'd generally favor moving it all else being equal.

Chuck
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion