2011/7/22 Stefan Behnel <stefan...@behnel.de>: > Vitja Makarov, 21.07.2011 20:57: >> >> 2011/7/21 Stefan Behnel<stefan...@behnel.de>: >>> >>> Robert Bradshaw, 21.07.2011 11:21: >>>> >>>> On Thu, Jul 7, 2011 at 2:13 PM, Vitja Makarov wrote: >>>>> >>>>> 2011/7/8 mark florisson >>>>>> >>>>>> In descr_get you create and return a new CyFunction with a __self__ >>>>>> set (note, not m_self) and in __call__ you put __self__ in the args >>>>>> tuple and the function as m_self, and then call the CyFunction using >>>>>> PyCFunction_Call. But copying and modifying PyCFunction_Call works >>>>>> just as well I suppose :) >>>>> >>>>> Yes, that would work) But I think CyFunction is too heavy for methods. >>>>> I've just realized that descr_get is called each time you access >>>>> method, >>>>> each time you call it and so on. >>>> >>>> True, but this is also the case for CPython methods and method >>>> descriptors. There's also an inefficiency in calling bound methods in >>>> that a new tuple needs to be created with the bound parameter as the >>>> first component. Perhaps we could do away with that as well with >>>> specialized unpacking code. It would simultaneously be a step forward >>>> and backwards in terms of compatibility, but we could do away with >>>> ever generating PyCFunctions, methods, and method descriptors. >>> >> >> Yeah, I was thinking about that too. >> >>> That sounds like a really cool optimisation path. We could get rid of one >>> indirection by replacing tp_call (originally PyCFunction_Call) directly >>> by >>> the real function entry point, i.e. the Python function wrapper (assuming >>> the DefNode refactoring has taken place by then). >>> >> >> +1 I think DefNode refactoring should be done first (Did we froget about >> that?) >> >>> It would also (somewhat) simplify the argument unpacking code, as that >>> would >>> no longer have to care about the METH_O and METH_NOARGS special cases. >>> They'd be handled naturally inside of the Python call wrapper. >>> >>> >>>> Perhaps >>>> a CEP is in order to nail down the behavior of the CyFunction object. >>> >>> +1, totally helps in figuring out the details. >> >> CEP for refactored DefNode would be a good idea too. > > Well, there's still the part I wrote for the generator CEP: > > http://wiki.cython.org/enhancements/generators#Pythonfunctionrefactoring > > >> As I rember the idea is to turn def node into cdef node with wrapper >> call function just like cpdef buf without C-level access. >> So here we have to decide how to how to match python function's >> signature and cdef one. > > I think that's mostly trivial - the argument unpacking code already does the > mapping for us. >
So the wrapper could pass all the args (including defaults) to underlaying C-function. That solves the problem. -- vitja. _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel