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
