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