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

[Charles R Harris]

2009/4/28 Stéfan van der Walt <stefan at sun.ac.za>

> 2009/4/28 Charles R Harris <charlesr.harris at gmail.com>:
> >> IIRC, we can expose NPY_FEATURE_VERSION as part of the API without
> >> breaking ABI compatibility, as long as we add it at the end of the API
> >> functions list.  As a hack, we can then check the length of the API
> >> functions list to make sure it is available before we call it.
> >
> > Why bother when you can combine it with NPY_VERSION and use the existing
> > API?
>
> We could, as long as NPY_VERSION always remains greater than its
> current value.  We considered this option at SciPy'08 -- can you
> remember why we decided to go for the "split" route instead?
>

No, I just vaguely remember it.


>
> When I implemented the change originally, I combined the two into one
> vaue, as can be seen in the reviewed patches:
>
> http://codereview.appspot.com/2946/show
>

We could do

#define NPY_ABI_VERSION xxxx
#define NPY_API_VERSION yyyy
#define NPY_VERSION ((xxxx << 16) || yyyy)

Since the current value is 0x01000009 we could start with xxxx == 0x0100 and
yyyy == 0x000A. I'm not sure how to handle the current 1.3.0 problem. Maybe
the best thing to do there is check the numpy release tag from the loaded
module and make a exception in the check. After all, things compiled against
1.4 should probably run under with 1.3. Or we could just bite the bullet and
make folks upgrade their numpy installations again.

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