[Numpy-discussion] PY_ARRAY_UNIQUE_SYMBOL is too far reaching?

[David]

On 05/04/2010 04:38 PM, Austin Bingham wrote:

>
> I admit I'm having trouble formulating questions to address my
> problems, so please bear with me.
>
> Say I've got a shared library of utilities for working with numpy
> arrays. It's intended to be used in multiple extension modules and in
> some places that are not modules at all (e.g. C++ programs that embed
> python and want to manipulate arrays directly.)
>
> One of the headers in this library (call it 'util.h') includes
> arrayobject.h because, for example, it needs NPY_TYPES in some
> template definitions. Should this 'util.h' define
> PY_ARRAY_UNIQUE_SYMBOL? Or NO_IMPORT? It seems like the correct
> answers are 'no' and 'yes', but that means that any user of this
> header needs to be very aware of header inclusion order. For example,
> if they want to include 'arrayobject.h' for their own reasons *and*
> they want NO_IMPORT undefined, then they need to be sure to include
> 'util.h' after 'arrayobject.h'.

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).

>From what I can see, the problem seems to be a conflation of two sets
> of symbols: those influenced by the PY_ARRAY_UNIQUE_SYMBOL and
> NO_IMPORT macros (broadly, the API functions), those that aren't
> (types, enums, and so forth.)

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

cheers,

David