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

Stéfan van der Walt stefan@sun.ac...
Wed Apr 29 02:10:17 CDT 2009

2009/4/29 David Cournapeau <david@ar.media.kyoto-u.ac.jp>:
> Stéfan van der Walt wrote:
>> We can already do this: simply choose a convention for NPY_VERSION and
>> NPY_FEATURE_VERSION so that they are related.
> By tracking, I meant more than just the actual number in the source
> code, like something in the documentation. So that if someone wants to
> know which function is present in which version of numpy, he can quickly
> find it in the documentation. Doxygen has a version field for
> documentation, I wonder whether we could use something like this for the
> C code.

I see a number of docstrings already have

.. versionadded:: 1.3.0

>    - always append NULL as the last item in PyArray_API, so that we can
> easily get the size of the API, and detect mismatch (a mismatch
> guarantees incompatibilities, but a match does not guarantee compatibility)

Good idea.

>     - the API is mostly changed when we add functions to the API, that
> is when either multiarray.txt or ufunc.txt is changed: we could track
> the checksum of both multiarray.txt and ufunc.txt, and make a
> relationship between the checksum and the C-API versions. Every time the
> code generator, it would check the checksum against this list, and barf
> in case of mismatch; this would remind us to update the version numbers
> accordingly.

I assume you are referring to ufunc_api_order.txt and
numpy_api_order.txt.  Fixing them by hashing should be fine; we must
just be very careful not to change those files by accident.  Also, are
we guaranteed that endlines and such will check out the same on the
different platforms?


More information about the Numpy-discussion mailing list