[Numpy-discussion] Managing Python with NumPy and many external libraries on multiple Windows machines
Charles R Harris
Mon Apr 27 21:17:01 CDT 2009
On Mon, Apr 27, 2009 at 7:43 PM, Charles R Harris <email@example.com
> On Mon, Apr 27, 2009 at 7:28 PM, David Cournapeau <firstname.lastname@example.org>wrote:
>> On Tue, Apr 28, 2009 at 9:56 AM, Charles R Harris
>> <email@example.com> wrote:
>> > Hmm... OK, I think that is because of the endianess function added to
>> > API. It is called during module load and since it isn't there for 1.2,
>> > crash. There is also a check for the API version that should have raised
>> > error, but evidently not.
>> Yes, this should have been detected.
>> > I think the endianess check should probably be
>> > moved to testing and not be done during the load. Or it can simply be
>> > removed from the interface and/or be implemented inline. I don't think
>> > having it in the interface is that important.
>> I am not sure I understand: it is expected that building software A
>> against B >= 1.3 cannot run with B < 1.3 (forward compatibility). It
>> is the same as a runtime error when running something with libfoo 1.2
>> but linked against 1.3, using a function 1.3 specific.
>> We should fix the undetected incompatibility, but I don't think we
>> should care about the incompatibility itself.
> I think you are right. So the API version check needs to be fixed.
Looks like NPY_FEATURE_VERSION needs to be checked *and* updated.
Unfortunately, it isn't part of the API, so can't be checked. That is
unfortunate, but I think there is an ugly way to merge it with NPY_VERSION
and fix the check, i.e., we can version the version number by setting the
top bit ;)
/* Binary compatibility version number. This number is increased
whenever the C-API is changed such that binary compatibility is
broken, i.e. whenever a recompile of extension modules is
#define NPY_VERSION 0x01000009
/* Minor API version. This number is increased whenever a change is
made to the C-API -- whether it breaks binary compatibility or not.
Some changes, such as adding a function pointer to the end of the
function table, can be made without breaking binary compatibility.
In this case, only the NPY_FEATURE_VERSION (*not* NPY_VERSION)
would be increased. Whenever binary compatibility is broken, both
NPY_VERSION and NPY_FEATURE_VERSION should be increased.
#define NPY_FEATURE_VERSION 0x00000001
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion