2010/12/1 Robert Kern <[email protected]>: > On 11/30/10 4:01 PM, Robert Bradshaw wrote: >> On Tue, Nov 30, 2010 at 1:57 PM, Robert Kern<[email protected]> wrote: >>> On 11/30/10 3:31 PM, Robert Bradshaw wrote: >>>> 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. >>> >>> ctypes/libffi is deliberately considered an optional component of Python for >>> several reasons, one of which is the lack of support on certain platforms. I >>> would say that it exists in a somewhat unique middle ground between "ships >>> with >>> Python" and "external dependency". >> >> Thanks for the perspective. Are there any good alternatives >> (especially that would be less of an "external" dependency)? > > I'm afraid not. > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless enigma > that is made terrible by our own mad attempt to interpret it as though it had > an underlying truth." > -- Umberto Eco > > _______________________________________________ > Cython-dev mailing list > [email protected] > http://codespeak.net/mailman/listinfo/cython-dev >
Don't worry about bfin support, that was just an example of unsupported arch. About use cases, I see only two now (am I right?): - Function that returns inner function - Function is passed as callback to plain C (object methods or nested). (It's okay when nested function is used inside cdef, cython can handle it.) In the libffi example new function bound_puts() is assebled it know how to call original puts_binding(). The real problem is when newly created function is passed to C code, We don't know when to call ffi_closure_free(). -- vitja. _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
