[Numpy-discussion] PY_ARRAY_UNIQUE_SYMBOL is too far reaching?

[Austin Bingham]

Hi everyone,

I've recently been developing a python module and C++ library in
parallel, with core functionality in python and C++ largely just
layered on top of the python (with boost.python.) In some cases,
however, for performance reasons, the C++ API "reaches into" the
python code via the C API, and this tends to happen very often with
numpy-related code.

As a result, I'm using the numpy C API a lot in my C++ library. To
make a long story short, I'm finding that there are many places where
I need to include numpy headers in my own headers (e.g. when a
template class uses part of the numpy API.) If the symbol I want in my
header is in ndarrayobject.h, it seems that I'm obligated to define
PY_ARRAY_UNIQUE_SYMBOL because that file includes __multiarray_api.h.
However, defining that macro in a header file seems like a bad idea
because of potential conflicts with headers from other libraries.

As a motivating example, I have a header which implements a
type-mapping template for numpy types. It maps at compile time between
the NPY_TYPES enum and actual C++ types. To get the NPY_TYPES
definitions, I have to include arrayobject.h. Even though my header
doesn't actually use the symbols that PY_ARRAY_UNIQUE_SYMBOL
influences, it seems that I need to define it; even without it being
defined, __multiarray_api.h leaves a PyArray_API definition in my
header.

So, am I missing something obvious? Or is there no way to access
symbols like NPY_TYPES without pulling in the PyArray_API functions?
If there isn't, would it be possible to restructure the headers so
that the symbols affected by PY_ARRAY_UNIQUE_SYMBOL are separated from
the others? Thanks.

Austin