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

Charles R Harris charlesr.harris@gmail....
Tue Apr 28 17:51:09 CDT 2009

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

> 2009/4/28 Charles R Harris <charlesr.harris@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.

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

More information about the Numpy-discussion mailing list