On Sat, Apr 14, 2012 at 11:39 PM, Stefan Behnel <stefan...@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. - Robert _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
