Support for Python side multiple inheritance / mixin classes

[oghm2]

I saw the discussion at clarifying the multiple inheritance non-support #1242 and note the branch multiple_inheritance which is rather out-of-date, and wonder if it would be possible to support the following scenario:

• a C++ class Child derived from Parent (and potentially Parent derived from Grandparent etc.) bound as Child
• a Python class Mixin
• a Python class Mixed(Mixin, Child)

When I try to define the class Mixed in Python, I get the error:
TypeError: nanobind types do not support multiple inheritance!

I understand that I could probably get this to work with a trampoline but it would be much simpler to be able to attach extra methods to a class in pure Python. This is a stumbling block when porting a pybind11 project to nanobind.

[vynazevedo]

You don't need a trampoline just to add Python methods to Child. A single Python subclass works:

class Mixed(Child):
    def extra(self):
        return self.value() + 1  # value() is a bound C++ method

I checked this with a small Parent / Child : Parent extension on nanobind 3.0.1: the added method works, inherited methods remain available, and the instance can still be passed to a C++ function taking const Parent&.

The restriction is specifically the two direct bases in Mixed(Mixin, Child). The Python subclass initializer rejects a bases tuple whose length isn't one, even if the other base is pure Python. Reversing the base order won't help, and a trampoline doesn't remove that check.

For a small mixin containing ordinary helper methods, assigning them on the single subclass can be enough:

class Mixed(Child):
    extra = Mixin.extra

That last workaround doesn't preserve mixin inheritance: avoid it if the methods depend on zero-argument super(), mixin initialization, or isinstance(obj, Mixin). In that case the helpers need refactoring or composition. A trampoline addresses a different need: dispatching C++ virtual calls to Python overrides.

[oghm2]

Thanks for your reply and sorry for introducing confusion re the trampoline, that is not what I need.

Your simple inheritance example works but is not sufficient for our use case. We have many classes that require the mixins (and potentially more than one mixin). It would be a significant refactor and degradation of the code if we had to bind the mixins to e.g. extra class members.

Apart from now being out-of-date, the multiple_inheritance branch appears to address this precise issue. Is there a particular reason not to pursue it?

[vynazevedo]

You're right @oghm2

I checked the multiple_inheritance commit. It specifically allows multiple Python bases while requiring exactly one direct nanobind base. Its tests cover both (BoundClass, PythonMixin) and (PythonMixin, BoundClass), initialize both bases, and check isinstance against each. It still rejects two nanobind bases. That is much closer to what you need than copying methods or introducing a trampoline.

I don't see a reason in #1242 to rule out pursuing that approach; the maintainer explicitly mentioned the branch and invited use cases. I can't speak to why it remains unmerged.

There is a concrete porting issue, though: the branch changes the old nb_type_init(), whereas the current implementation initializes Python subclasses through nb_type_init_py() and takes the C++ type metadata from tp_base. Simply removing the multiple-bases check would not establish that the selected base and instance layout are valid.

For a revived patch, your Mixed(MixinA, MixinB, Child) case would make a useful regression test: check the MRO and cooperative super() behavior, both mixins' initialization, isinstance, and passing the result to C++ as Parent&. The existing branch tests don't establish all of that. I reviewed the diff, but haven't ported or run the branch against current nanobind.

[wjakob]

@oghm2 Please see commit 32c595d.

[oghm2]

Thanks @wjakob that's fantastic!