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 _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
