On Thu, May 6, 2010 at 3:08 AM, Austin Bingham <[email protected]>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
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
