You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Server().init appears to have no call to super(), which breaks MRO when creating a class user Server() as one of several baseclasses (multiple inheritance). This can break other class's code because it fails to call init() on classes that come after Server().init() in the MRO. Please add a super() call to all class initializers that can be sub-classed.
Thanks for the issue and PR, and sorry it took some time to respond.
To be honest, I never had the need to use multiple inheritance with fmrest, that's why those supers are missing. I would be interested in learning more about your use case, though.
So my use case is fairly straightforward - I have a standard practice of adding logging to most of my classes. I do this by making each class a Logger, like this:
class MyFmDb(MyLogger, Server):
This is the classic case of multiple inheritance which MRO is built around.
If all the super() calls were constructed properly, I could simply call "super()", pass any args my constructor didn't consume, and be done with it. Instead, I have to manually ensure that I setup my own classes first, then call super to your "Server" base class.
I can handle this case in my own source code because that's where the inheritance tree splits - but it's especially bad if the problem is buried in a library.
Activity
davidhamann commentedon Oct 6, 2020
Thanks for the issue and PR, and sorry it took some time to respond.
To be honest, I never had the need to use multiple inheritance with fmrest, that's why those
supers are missing. I would be interested in learning more about your use case, though.I also added a few comments on your PR.
rothloup commentedon Oct 18, 2022
Looks like it took me even longer to respond.
So my use case is fairly straightforward - I have a standard practice of adding logging to most of my classes. I do this by making each class a Logger, like this:
class MyFmDb(MyLogger, Server):
This is the classic case of multiple inheritance which MRO is built around.
If all the super() calls were constructed properly, I could simply call "super()", pass any args my constructor didn't consume, and be done with it. Instead, I have to manually ensure that I setup my own classes first, then call super to your "Server" base class.
I can handle this case in my own source code because that's where the inheritance tree splits - but it's especially bad if the problem is buried in a library.