[Numpy-discussion] NumPy SVN broken

[Charles R Harris]

On Wed, Oct 7, 2009 at 6:37 AM, David Cournapeau <cournape at gmail.com> wrote:

> On Wed, Oct 7, 2009 at 9:31 PM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> >
> >
> > On Wed, Oct 7, 2009 at 2:06 AM, David Cournapeau <cournape at gmail.com>
> wrote:
> >>
> >> On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris
> >> <charlesr.harris at gmail.com> wrote:
> >> >
> >> >
> >> > Looks like a clue ;)
> >>
> >> Ok, I fixed it here:
> >>
> >> http://github.com/cournape/numpy/tree/fix_abi
> >>
> >> But that's an ugly hack. I think we should consider rewriting how we
> >> generate the API: instead of automatically growing the API array of
> >> fptr, we should explicitly mark which function name has which index,
> >> and hardcode it. It would help quite a bit to avoid changing the ABI
> >> unvoluntary.
> >>
> >
> > I'm thinking the safest thing to do is to move the new type to the end of
> > the list.
>
> That's what the above branch does.
>
> > I'm not sure what all the ramifications are for compatibility to
> > having it stuck in the middle like that, does it change the type numbers
> for
> > all the types after?
>
> Yes, there is no space left between the types declarations and the
> first functions. Currently, I just put things at the end manually, but
> that's really error prone.
>
> I am a bit lazy to fix this for real (I was thinking about using a
> python dict with hardcoded indexes as an entry instead of the current
> .txt files, but this requires several changes in the code generator,
> which is already not the greatest code to begin with).
>
>
What I'm concerned about is that, IIRC, types in the c-code can be
referenced by their index in a list of types and that internal mechanism
might be exposed to the outside somewhere. That is, what has happened to the
order of the enumerated types? If that has changed, and if external code
references a type by a hard-wired number, then there is a problem that goes
beyond the code generator. The safe(r) thing to do in that case is add the
new type to the end of the enumerated types and fix the promotion code so it
doesn't try to rely on a linear order.

I expect Robert can give the fastest answer to that question.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20091007/65b960b7/attachment.html>