> 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 _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
