On Thu, May 6, 2010 at 8:21 AM, Charles R Harris <[email protected]>wrote:
> > > 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. > > Go ahead and open a ticket and provide a patch. Mark it as needs review. Chuck
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
