On Thu, Apr 19, 2012 at 11:56 AM, Dag Sverre Seljebotn
<d.s.seljeb...@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:
@cython.inline
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")
scipy.integrate.quad(square_double)
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
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
