[Cython] CEP1000: Native dispatch through callables

Nathaniel Smith njs at pobox.com
Thu Apr 19 13:20:47 CEST 2012

On Thu, Apr 19, 2012 at 11:56 AM, Dag Sverre Seljebotn
<d.s.seljebotn at astro.uio.no> wrote:
> I thought of some drawbacks of getfuncptr:
>  - Important: Doesn't allow you to actually inspect the supported
> signatures, which is needed (or at least convenient) if you want to use an
> FFI library or do some JIT-ing. So an iteration mechanism is still needed in
> addition, meaning the number of things for the object to implement grows a
> bit large. Default implementations help -- OTOH there really wasn't a major
> drawback with the table approach as long as JIT's can just replace it?

But this is orthogonal to the table vs. getfuncptr discussion. We're
assuming that the table might be extended at runtime, which means you
can't use it to determine which signatures are supported. So we need
some sort of extra interface for the caller and callee to negotiate a
type anyway. (I'm intentionally agnostic about whether it makes more
sense for the caller or the callee to be doing the iterating... in
general type negotiation could be quite complicated, and I don't think
we know enough to get that interface right yet.)

The other other option would be to go to the far other end of
simplicity, and just forget for now about allowing multiple signatures
in the same object. Do signature selection by having the user select
one explicitly:

def square(x):
    return x * x

# .specialize is an un-standardized Cython interface
# square_double is an object implementing the standardized C-callable interface
square_double = square.specialize("d->d")

That'd be enough to get started, and doesn't rule out later extensions
that do automatic type selection, once we have more experience.

-- Nathaniel

More information about the cython-devel mailing list