[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 15:00:34 CDT 2009

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

> 2009/4/28 Charles R Harris <charlesr.harris@gmail.com>:
> > 2009/4/28 Stéfan van der Walt <stefan@sun.ac.za>
> >> We can already do this: simply choose a convention for NPY_VERSION and
> >> NPY_FEATURE_VERSION so that they are related.
> >
> > NPY_VERSION has been 0x01000009 since 1.0. NPY_FEATURE_VERSION was added
> for
> > 1.2, but is useless since it can't be obtained through the API. I suggest
> we
> > keep only NPY_VERSION but split it into two parts, the upper 16 bits for
> > changes that require extensions to be recompiled, and the lower 16 bits
> for
> > API changes that are backward compatible, so that the next release should
> > have version 0x0100000A. What to do with the current release is another
> > question. If we change the version for a bugfix release it won't be
> > compatible with 1.3.0. Hmm...
> The current system does exactly this. The ABI compatibility is tracked
> in NPY_VERSION and the C API version is tracked in
> NPY_FEATURE_VERSION.   NPY_VERSION is only visible where it is needed
> -- during compilation of extensions.

It is needed when the extension is loaded, that is why the very first
function in the API returns it. Otherwise it is impossible to check if
extensions compiled against one version of numpy can be loaded when another
version of numpy is present. You need to know what API numpy presents and
that can be different than the API the extension was compiled against.

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

More information about the Numpy-discussion mailing list