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