[Cython] CEP1000: Native dispatch through callables

[Dag Sverre Seljebotn]

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 
their native-call
  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 
with Cython<->Cython.

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)
scipy.integrate(mycapsule)

just saying that the fast-callable aspect isn't everything, passing the 
function pointer around was how this started.

Dag