[Cython] CEP1000: Native dispatch through callables

Stefan Behnel stefan_ml at behnel.de
Sun Apr 15 08:39:46 CEST 2012


Robert Bradshaw, 15.04.2012 08:32:
> On Sat, Apr 14, 2012 at 11:16 PM, 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?
> 
> That's certainly our (initial?) usecase, but there's no need to limit
> the protocol to this.

I think the question here is: is this supposed to be a best effort protocol
for bypassing Python calls, or would it be an error in some situations if
no matching signature can be found?

Stefan


More information about the cython-devel mailing list