[Cython] PEP 3135 -- New Super

[Vitja Makarov]

2011/7/22 Stefan Behnel <stefan_ml at behnel.de>:
> Vitja Makarov, 21.07.2011 20:57:
>>
>> 2011/7/21 Stefan Behnel<stefan_ml at 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.