On 11/30/2010 06:35 AM, Robert Bradshaw wrote: > On Mon, Nov 29, 2010 at 9:20 PM, Vitja Makarov<[email protected]> > wrote: > >> 2010/11/30 Robert Bradshaw<[email protected]>: >> >>> On Mon, Nov 29, 2010 at 12:27 PM, Greg Ewing >>> <[email protected]> wrote: >>> >>>> Stefan Behnel wrote: >>>> >>>> >>>>> * it makes the inner C function directly callable, thus making it easier >>>>> to >>>>> implement things like cpdef functions and generators on top. >>>>> >>>> If you mention the name of such a function without calling it, >>>> does it refer to the C function or the Python function? >>>> >>> That would depend on the context in which it's being used. >>> Essentially, the as_variable attribute would be set, allowing it to >>> coerce to a Python object if need be. >>> >>> >> I see problem with closures here where should scope object be created >> in C function or in wrapper? >> > The only handle you can get of a closure object is a Python one. > (Well, eventually we want to have cdef closures, but we're not there > yet, and wouldn't be compatible with cdef functions--we'd probably > expose them as structs with a state and function pointer attributes.) >
Just for reference: Carl recently made me aware that ctypes contain some code to proxy Python functions to C function pointers. And apparently it contains a small compiler that creates new CPU code on demand for this. I'm not sure how well that would be exposed for our purposes, if it has a C API or not. (I haven't really looked at this myself.) Being able to create a closure in Cython and pass it as an ordinary C function callback, without having to manage the context manually, would be a really cool feature! And with such a mini-compiler it is possible. (Same idea applies to a concept of "pointer to bound cdef method") Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
