I'm on Robert's side on all this for the same reasons. In short, +1
for (1) and -1 for (2) and (3).
On Thu, Nov 13, 2008 at 6:40 AM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
> On Nov 10, 2008, at 2:46 AM, Dag Sverre Seljebotn wrote:
>
>> A discussion recently came up on the NumPy mailing list, and it
>> inspired
>> me to focus on this usability issue:
>>
>> cdef extern from "test.h":
>> ctypedef int type_a
>> ctypedef int type_b
>> cdef type_a* ptr1 = NULL
>> cdef type_b* ptr2 = ptr1
>>
>> Now, it might happen (like with NumPy) that type_a and type_b are
>> defined as seperate types on some platforms and the same on others
>> (through #ifdefs). Partly this is relied upon currently, making the
>> situation a bit confusing, especially for new users.
>>
>> Possible solutions:
>>
>> 1) Make all external types pointer-incompatible. So "ptr2=ptr1" above
>> will always fail, and an explicit cast is needed.
>
> I think this is probably the way to go. Presumably there's a reason
> to have to separate times.
>
>> 2) Introduce a new keyword, something like unknown_size:
>>
>> cdef extern from "test.h":
>> ctypedef unknown_size int type_a
>> ctypedef long type_b # we know this is always "long"
>> ...
>>
>> which trigger pointer-incompatability with anything. NB! At the same
>> time, all external primitive types are checked for the right
>> declaration
>> in Cython at module startup time:
>>
>> if (sizeof(type_b) != sizeof(long) || ((type_a)-1) != ((type_b)-1) ||
>> ((type_a)0.5) != ((type_b)0.5))) { /*raise exception*/ }
>>
>> (Not sure if that float check will work though, might need to do a
>> division instead.)
>
> I have to admit I'm not a fan either of the new keyword or waiting
> 'till runtime to throw the error.
>
>> 3) Complex interaction with the C compiler so that Cython and the C
>> compiler work "in one step". The Cython core is simplified so that it
>> never checks pointer assignment compatability, but rather take any
>> error
>> the C compiler gives and translates it back to an error to the Cython
>> user. Obviously not a short-term solution but if this is a long-term
>> solution it might be enough reason not to bother with this for now.
>> This
>> seems to be the most stable solution, but it does give away the
>> possibility to seperate the Cython and C compilation stages as some
>> people are fond of doing.
>
> The biggest problem with 2 and 3 is that people often ship the .c
> files and it is compiled/run on the (end-users) machine. Much worse
> to delay the error to this point, and it may work on some machines
> and not on others. Better to raise an error at Cython compile time an
> force the programmer to think about what to do.
>
> - Robert
>
>
> _______________________________________________
> Cython-dev mailing list
> [email protected]
> http://codespeak.net/mailman/listinfo/cython-dev
>
--
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
