[Cython] CEP1000: Native dispatch through callables
Dag Sverre Seljebotn
d.s.seljebotn at astro.uio.no
Sun Apr 15 08:33:24 CEST 2012
On 04/15/2012 08:16 AM, Stefan Behnel wrote:
> Robert Bradshaw, 15.04.2012 07:59:
>> On Sat, Apr 14, 2012 at 2:00 PM, mark florisson wrote:
>>> There may be a lot of promotion/demotion (you likely only want the
>>> former) combinations, especially for multiple arguments, so perhaps it
>>> makes sense to limit ourselves a bit. For instance for numeric scalar
>>> argument types we could limit to long (and the unsigned counterparts),
>>> double and double complex.
>>> So char, short and int scalars will be
>>> promoted to long, float to double and float complex to double complex.
>>> Anything bigger, like long long etc will be matched specifically.
>>> Promotions and associated demotions if necessary in the callee should
>>> be fairly cheap compared to checking all combinations or going through
>>> the python layer.
>> True, though this could be a convention rather than a requirement of
>> the spec. Long vs.< long seems natural, but are there any systems
>> where (scalar) float still has an advantage over double?
>> Of course pointers like float* vs double* can't be promoted, so we
>> would still need this kind of type declaration.
> Yes, passing data sets as C arrays requires proper knowledge about their
> memory layout on both sides.
> OTOH, we are talking about functions that would otherwise be called through
> Python, so this could only apply for buffers anyway. So why not require a
> Py_buffer* as argument for them?
Is the proposal to limit the range of types valid for arguments?
I'm a bit wary of throwing this into the mix. We know very little about
the callee, they could decide:
a) To only export a C function and have an exeption-raising __call__
b) To accept ctypes pointers in their __call__, and C pointers in
c) They can invent their own use for this!
I think agreeing on a CEP gets a lot simpler, and the result cleaner, if
we focus on "how to describe C functions for the purposes of calling
them" (for various usecases), and leave "conventions for recommended
signatures" for CEP 1001.
In Cython, we could always export a fully-promoted-scalar function first
in the list, and always try to call this first, which would work well
BTW, when Travis originally wanted a proposal on the NumPy list he just
wanted it for "a C function"; his idea was something like
mycapsule = numbaize(f)
just saying that the fast-callable aspect isn't everything, passing the
function pointer around was how this started.
More information about the cython-devel