On Tue, Nov 30, 2010 at 1:04 PM, Vitja Makarov <[email protected]> wrote:

> I don't like the idea to add one more external dependency. But if that
> really helps its okay.

It's not an external dependency if it ships with Python. Actually,
ctypes didn't ship with Python until 2.5, so that may be an issue. I'm
thinking we'd only use it where we couldn't do it otherwise.

> Also libffi is not supported on blackfin architecture :(

Well, it'd probably be a longer time before we supported blackfin if
we were to roll our own... Do you have any other alternatives? I
suppose we could compile a fixed number of dummy functions

    int foo1(int arg1, int arg2) { return func_array[1](data_array[1],
arg1, arg2); }

but then we'd have to decide the upper limit ahead of time, and it
seems rather messy and wasteful.

> Here is simple example from libffi documentation:

...

> I don't actually understand how do you want to use libffi in Cython.
> Can you provide some usecase, please?

Suppose you have a c library that takes a function pointer callback,
and you want to use a Python callable as the callback. To do this you
would create a closure that translates the arguments and has the
Python callable as the state. Another usecase would be for actual
closures, e.g.

    cdef double (*add_n(double n))(double):
        cdef f(double a):
            return a + n
        return &f

    cdef double (*my_func)(double) = add_n(3)

(I have to admit that C function pointer syntax is pretty atrocious...
perhaps we can offer a better alternative?) They'd be useful for bound
cdef methods as well, so one could do something like


cdef extern from ...:
     double integrate(double (*f)(double), double a, double b)

cdef class MyEvaluator:
    cdef double eval(double):
        raise NotImplementedError # override

cdef MyEvaluator f = ...
print integrate(f.eval, 0, 10)

It's possible that we could handle much of this ourselves with a
struct containing a (raw) function pointer and void* state, but we'd
need something more to pass things to external libraries.

- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to