[Cython] CEP1000: Native dispatch through callables
robertwb at gmail.com
Sun Apr 15 09:00:34 CEST 2012
On Sat, Apr 14, 2012 at 11:39 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> 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?
It may be an error in some cases. This isn't just about avoiding
Python calls; Dag just barely summed this up quite nicely.
More information about the cython-devel