ticket 2228: Scientific package seeing ABI change in 1.6.x
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?
Ralf
P.S. that ticket has escaped the Github move.
On Tue, Oct 30, 2012 at 4:08 PM, Ralf Gommers ralf.gommers@gmail.comwrote:
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
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
On Tue, Oct 30, 2012 at 9:26 PM, Travis Oliphant travis@continuum.iowrote:
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.
<snip>
Chuck
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.iowrote:
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?
Ralf
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
On Tue, Oct 30, 2012 at 6:08 PM, Ralf Gommers ralf.gommers@gmail.com wrote:
[...] P.S. that ticket has escaped the Github move.
The github move only included up to 2225 or so. Anything after that will have to be imported when Trac is redirected to github. I believe David Cournapeau is going to do that at some point (hopefully soon).
Ray
participants (4)
-
Charles R Harris -
Ralf Gommers -
Thouis (Ray) Jones -
Travis Oliphant