[Numpy-discussion] NumPy SVN broken

[Charles R Harris]

On Wed, Oct 7, 2009 at 6:59 AM, Charles R Harris
<charlesr.harris at gmail.com>wrote:

>
>
> 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.
>
>
Here, for instance:

"The various character codes indicating certain types are also part of an
enumerated
list. References to type characters (should they be needed at all) should
always use
these enumerations. The form of them is NPY <NAME>LTR where <NAME>"

So those macros will generate a hard-coded number at compile time, and
number that might have changed with the addition of the new types.

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