On 04/15/2012 08:16 AM, 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?
Is the proposal to limit the range of types valid for arguments?
I'm a bit wary of throwing this into the mix. We know very little about
the callee, they could decide:
a) To only export a C function and have an exeption-raising __call__
b) To accept ctypes pointers in their __call__, and C pointers in
their native-call
c) They can invent their own use for this!
I think agreeing on a CEP gets a lot simpler, and the result cleaner, if
we focus on "how to describe C functions for the purposes of calling
them" (for various usecases), and leave "conventions for recommended
signatures" for CEP 1001.
In Cython, we could always export a fully-promoted-scalar function first
in the list, and always try to call this first, which would work well
with Cython<->Cython.
BTW, when Travis originally wanted a proposal on the NumPy list he just
wanted it for "a C function"; his idea was something like
mycapsule = numbaize(f)
scipy.integrate(mycapsule)
just saying that the fast-callable aspect isn't everything, passing the
function pointer around was how this started.
Dag
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
