[Numpy-discussion] PY_ARRAY_UNIQUE_SYMBOL is too far reaching?

[Charles R Harris]

On Thu, May 6, 2010 at 3:08 AM, Austin Bingham <austin.bingham at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20100506/f719b2c4/attachment.html>