[Cython] Problem with final cdef methods

Stefan Behnel stefan_ml at behnel.de
Thu Aug 29 10:24:34 CEST 2013


Nikita Nemkin, 29.08.2013 09:19:
> On Thu, 29 Aug 2013 12:57:19 +0600, Stefan Behnel wrote:
>> Nikita Nemkin, 29.08.2013 08:24:
>>> I have solved it for myself by storing BOTH types in the method entry
>>> (Entry.type for the actual CFuncDef type and Entry.prev_type for the vtable
>>> slot type). By using correct types in
>>> generate_exttype_final_methods_declaration()
>>> and generate_exttype_vtable_init_code() the problem is avoided.
>>> You can see the patch here
>>> https://github.com/nnemkin/cython/compare/final_subtypes
>>
>> Interesting. Your change dates back a while already. Were you planning to
>> clean it up in some way before you submit it as pull request?
> 
> That was the plan.
> My solution is kind of stopgap (even the name "prev_type" makes me cringe),

Yes, not the ideal name.


> but "proper" solution would require some serious redesign and rewrite work,
> which may be unwise in itsef. So I got stuck and left it behind.
> 
> If you want the problem fixed with minimal changes to the Cython
> codebase, you can use my approach.

For closures, we use an "outer_entry" that refers to the same variable
Entry in the outer scope. We could do something similar for methods,
basically a reference to the overridden base type method. To find out the
vtable type, you'd go up the Entry hierarchy and look up the type of the
original method definition. That could be hidden behind a method or even a
property.


> BTW I havent thoroughly tested that patch. It works for me
> in my environment and passes the test suite, but that's it.

As long as it also fixes the test I added, I'm happy. :)

I would expect the Sage tests to catch any remaining issues. They are
pretty subtype heavy.

Stefan



More information about the cython-devel mailing list