[Cython] PEP 3135 -- New Super

Stefan Behnel stefan_ml at behnel.de
Thu Jul 21 18:29:40 CEST 2011

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.

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).

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.


More information about the cython-devel mailing list