[Cython] [cython-users] Confused by user's guide

Stefan Behnel stefan_ml at behnel.de
Tue Aug 13 06:58:43 CEST 2013


Robert Bradshaw, 13.08.2013 06:13:
> def do_math2(top_temp, bottom_temp):
>     cdef int top = top_temp
>     cdef int bottom = bottom_temp
>     return do_math_c(top, bottom)
> 
> cdef do_math_c(int top, int bottom):
>     return top / bottom
> 
> which doesn't really matter to the user except that there may be some
> cases (in the future) where we can extract and call do_math_c
> directly.
> 
> Of course, this is exactly what cpdef is, which has got me thinking
> whether we need a separate keyword for this, or if we could simply
> make all def functions cpdef automatically. One place that's different
> is for exported cdef classes where c(p)def methods must be declared in
> the .pxd file, but we could perhaps handle this case by allowing them
> to be declared as plain cdef (or "def") methods there. Does anyone see
> any drawbacks to this? (I suppose there's a little overhead in the
> check-if-overridden dispatch.)

We could detect which def functions/methods are actually being called
inside of the module, and then only drop those calls into C. We already do
this for final classes.

I think the main problem is the way cpdef is currently implemented. It
declares a cdef function with a def wrapper. If it declared a def function
instead, it would be easier to do the switch later in the pipeline for
normal def functions. But as you noted, if we just unified that into always
declaring the two entry points up-front, for both def and cpdef functions,
preferably using the existing signature override mechanism, then we'd have
the means to switch at any point.

Trying to do this across modules is less straight forward, as it would
override existing user declarations in .pxd files (if they exist). It could
be done if we automatically generate a .pxd from a .pyx file, though.

Stefan



More information about the cython-devel mailing list