[Numpy-discussion] Managing Python with NumPy and many external libraries on multiple Windows machines

[Charles R Harris]

On Mon, Apr 27, 2009 at 7:43 PM, Charles R Harris <charlesr.harris at gmail.com
> wrote:

>
>
> On Mon, Apr 27, 2009 at 7:28 PM, David Cournapeau <cournape at gmail.com>wrote:
>
>> On Tue, Apr 28, 2009 at 9:56 AM, Charles R Harris
>> <charlesr.harris at gmail.com> wrote:
>>
>> > Hmm... OK, I think that is because of the endianess function added to
>> the
>> > 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
>> an
>> > 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
   needed. */
#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

 Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20090427/594b6e20/attachment.html>