Stumbled upon this really bizarre issue in flame while developing, wondered if anyone had any insights into why this is happening? If not, at the very least I hope this post will be useful to any other developers confused as to why their code is not working.
To begin, I’m running flame 2025, which uses python 3.11.5, but have tested on flame 2026 as well and got the same results.
Basically, the way multiple inheritance and super works in python is that the super call will try to find the first instance of that method in parent classes as defined by the method resolution order.
So if I start with a simple example;
class A:
def __init__(self, a=None):
print("Enter A")
self.a = a
print("Exit A")
class B:
def __init__(self, b=None):
print("Enter B")
self.b = b
print("Exit B")
class C(A, B):
def __init__(self):
"""Initialize the class."""
print("Enter C")
super().__init__()
print("Exit C")
We see that class C has as super call to __init__ which we would expect to resolve to class A’s init method. This is true when all the classes are in the same module, and we get the expected output - from my python console in flame;
[07/09/2025 10:48:16 AM]
>>> import sys
>>> sys.path.insert(0, '/users/edwardspencer/pipeline/experiments/super-mro')
>>> from single import C
[07/09/2025 10:49:08 AM]
>>> c = C()
Enter C
Enter A
Exit A
Exit C
So far, so good. Now if we break up our classes into separate modules (as is normal for large software projects) so that we have the following structure;
.
├── multifile
│ ├── a.py
│ ├── b.py
│ └── c.py
└── single.py
Then we try the same thing as above (before you ask, this is a brand new session of flame);
[07/09/2025 10:50:23 AM]
>>> import sys
>>> sys.path.insert(0, '/users/edwardspencer/pipeline/experiments/super-mro')
>>> from multifile.c import C
[07/09/2025 10:50:25 AM]
>>> c = C()
Enter C
Enter A
Enter B
Exit B
Exit A
Exit C
As you can see, C init is called, it enters A first and then it enters B.
This might not seem like a big deal but 1) if the method signatures of either of the base classes differ you’ll get error and 2) you’re unintentionally running code which could have unexpected consequences.
I should also further note that outside of flame, e.g. running this code in regular python you only get the first behaviour. It is common practice in DCC development to test your GUIs outside of the DCC because it’s significantly faster not waiting for the application to load before running the small bit you need to test - however with flame changing how python works at such a fundamental level it’s pretty hard to have confidence in that testing…