Multiple inheritance

[robertwb]

No description provided.

[scoder]

Looks like you changed the indentation space in a couple of places (4->2). I would prefer sticking with the standard of 4 spaces everywhere.

[robertwb]

Not intentionally, thanks for catching.

[scoder]

I know, the code was like this before, so this comment is really misplaced here (sorry), but now that this old code is touched anyway, let me say that it would be a good opportunity to clean up this kind of useless level of indentation. If the code handles an error case, it should just say so and bail out early, instead of using lengthy indented if-blocks without an else. I don't mind long functions at all, as long as their structure is simple. But indented conditional blocks increase the complexity because if I can't see where an if-block ends, I have to assume that there is an else-case (and mentally prepare for it). If there is no else-case after a long block, then the if-block probably shouldn't be there in the first place, but be replaced by a short error handling case of the reversed condition, or be moved into a separate method entirely.

[robertwb]

Sure.

[scoder]

Hmm. Eventually, we will have to switch to heap-types anyway to properly support PEP 489, submodules, reloading, etc. I understand that this doesn't have to happen right now, but you would probably agree that this flag unsetting seems like a fairly crude hack.

[robertwb]

Yes, this is an ugly hack (and one of my hesitations for the whole PR) but I couldn't figure out a way around it without making everything heap allocated (a much bigger change, though, as you said, we may need to go there).

[scoder]

IdentifierStringNode is better here.

[scoder]

;)

[scoder]

I'd rather call sign_and_name() here instead of relying on the output of str().

[scoder]

Nice feature!

[scoder]

Hmm, I think this might have an impact on the __richcmp__() generation:

https://github.com/cython/cython/blob/0.27.3/Cython/Compiler/ModuleNode.py#L1807

We should now also look into the Python base classes for special methods, and (I think) also generally delegate missing special methods to a runtime lookup.

[robertwb]

Good point, these special methods that delegate to other (sets of) special methods need more sophisticated handling. Seems this may also be an issue for Python classes that inherit from cdef classes with this kind of special method.

[cvanelteren]

Are there any plans for multiple extension inheritance (cdef class)?

f

[da-woods]

Are there any plans for multiple extension inheritance (cdef class)?

I wouldn't think so. It's a limitation of how Python handles extension types (i.e. any type defined as a C struct). Try class C(int, dict): pass for example.

[cvanelteren]

I am a bit unfamiliar with the lower level internals of python but that would also imply that multi-level inheritance is out for extensions written in cython? I currently this problem with a 'need' for a third layer of class inheritance. According to the docs this is fine for normal python objects but the not for extensions, I was wondering why.

[da-woods]

I am a bit unfamiliar with the lower level internals of python but that would also imply that multi-level inheritance is out for extensions written in cython? I currently this problem with a 'need' for a third layer of class inheritance. According to the docs this is fine for normal python objects but the not for extensions, I was wondering why.

The basic problem for multiple inheritance is that an extension type gets translated into:

struct some_internal_struct {
   PyObject_HEAD;
   int some_detail; // just as an example of data that might be part of the type
};

In order to function properly you really need exactly one PyObject_HEAD since it's this that holds the details of the reference counting.

Single inheritance is fairly simple:

struct some_derived_type {
    some_internal_struct base;
    double other_contents_for_example;  // just as an example of data that might be part of the type
}

For multiple inheritance though it's impossible to include extension types in some_derived_type while preserving their layout and keeping only one PyObject_HEAD. This doesn't apply to normal Python objects because their attributes are mostly based around a single dict rather than C structures.

---

Multi-level inheritance is no problem and has worked for a long long time. You can have as many "layers" of inheritance as you like (so C inherits from B inherits from A); you just can't have C inherits from A and B.

struct a_third_level_derived_type {
    some_derived_type base;
    // more detials
};

This fulfils all the requirements: one PyObject_HEAD at the start of the struct.

---

However, if you have questions about a specific implementation problem then you should follow it up on the cython-users mailing list rather than this PR.

[scoder]

Just to clarify, you
a) can create a Python class that inherits from a single cdef class and one or more Python classes
b) can create a cdef class that inherits from a single cdef class and one or more Python classes (this is what this PR is about)
c) cannot create a cdef class that inherits from more than one cdef class

The third point only diverges slightly from Python's own behaviour. You cannot create a Python class that inherits from two builtin/extension types with different object layouts (e.g. class PyClass(list, tuple)), but you can create a Python class that inherits from two builtin/extension types that have the same object layouts (e.g. class PyClass(SyntaxError, ValueError)).

This restriction could be lifted, but it's probably less interesting than the change in this PR.

Note that Python classes are not "slow" or "bad" per se. If you think that you have a specific need for inheriting from more than one cdef class which cannot (more or less) easily be resolved by using (compiled) Python classes, then I would suggest opening a new feature ticket that describes your use case and the reasons why a mix of cdef and Python classes cannot work here.

If it's unclear for you how to handle a specific use case with the current feature set, then I would second @da-woods' suggestion of asking on the cython-users mailing list for help.