On Thu, May 6, 2010 at 8:21 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:

On Thu, May 6, 2010 at 3:08 AM, Austin Bingham <austin.bingham@gmail.com> wrote:
>> they'd likely crash.
> Really?

I base that on the assumption that they'd not know to call
import_array() in that translation unit. This seems like a reasonable
assumption because, by defining the macros as such, they are strongly
implying that they expect the API functions to be imported for their
definition of PY_ARRAY_UNIQUE_SYMBOL in some other place. Of course,
their powers of inference and patience might be very strong, in which
case they'd make sure to define those pointers, but that seems like a
lot to ask of users.

> Wouldn't it be really easy to check for this situation, i.e. augment
> the inclusion guards by some "if included before, but
> PY_ARRAY_UNIQUE_SYMBOL/NO_IMPORT settings are different than the last time,
> fail and tell the user about it"?
> At least that would give a compile error at an earlier point in time.

Yes, that might be easy to do, and it's probably a good idea, but it's
not an argument against normalizing (to abuse a term) the headers
where possible. All the complication revolves around the API function
pointers; as a user of numpy, I find it a bit frustrating that I have
to concern myself with those complications when what I *really* want
has nothing to do with those functions.

Welcome to open source and the joys of backward compatibility ;) I like your idea for breaking the header up, we really do need to try working on the header situation and I think your suggestion could be helpful without breaking current usage.

Go ahead and open a ticket and provide a patch. Mark it as needs review.