[Numpy-discussion] PY_ARRAY_UNIQUE_SYMBOL is too far reaching?

[Austin Bingham]

> I still don't understand why you cannot just include the header file as
> is (without defining any of NO_IMPORT/PY_ARRAY_UNIQUE_SYMBOL).

I guess the real point is that no matter what definition (or lack
thereof) that I have for these macros, I still introduce header order
dependencies to users of my library if I include arrayobject.h in one
of my headers.

Suppose I defined neither macro in my 'util.h', and that I included
'arrayobject.h'. If a user of my library did this:

  #include <mylib/util.h> // <-- my library's header

  #define PY_ARRAY_UNIQUE_SYMBOL MY_UNIQUE_SYMBOL
  #define NO_IMPORT
  #include <numpy/arrayobject.h>

  ...

they'd likely crash. The inclusion of arrayobject.h in util.h
activates the include guards in arrayobject.h, so the second inclusion
has no real effect; their calls to numpy API methods would be made
against garbage pointers. As a result, unless my library's user is
keenly aware of what's going on, the API function pointers will not
get set properly.

In this case, of course, reordering the includes will probably fix the
issue. But it's a classic example of an unhygienic header, and I think
we can avoid this very easily (see below).

> numpy headers are really messy - way too many macros, etc... Fixing it
> without breaking API compatibility is a lot of work, though,

That may be true in general, but it looks like there might be a simple
solution in this case. In my copy of numpy (1.3.0), I've moved
everything in ndarrayobject.h between the "CONFUSE_EMACS" stuff and
the inclusion of "__multiarray_api.h" into a new header, nonfunc_api.h
(though this is clearly a temporary name at best!). ndarrayobject.h
now includes nonfunc_api.h in place of all of the removed code, and my
util.h includes nonfunc_api.h instead of arrayobject.h.

The result is that existing users of the numpy API are (I believe)
completely unaffected. However, the new header makes it possible to
include a lot of type definitions, enumerations, and all sorts of
other stuff...in my thinking, everything from ndarrayobject.h that
*doesn't* depend on the macros...without adding the burden of actually
needing to consider the macros.

FWIW, this arrangement seems to work for my projects. I haven't
applied this patch, rebuilt numpy, and run the unittests, though I'd
like to when I get a chance.

Austin