super() in Python

[JKSH]

@Denni-0 said in Signals blocked from widget in QMdiSubwindow but not in QDilaog:

Hmm okay went and looked that up again and my bad you did use super() the current python3 way

Thank you for acknowledging this.

However as I pointed out in the code I posted using super() in python carries with it issues and currently bugs.... frankly in Python you are gaining nothing by using it and losing a lot.

I notice that you've been actively discouraging users from using super() in different threads. However, while you've told us that it causes problems, I haven't found a post from you where you showed how it causes problems. If you have indeed made such a post, please point me to it. Without proof, your statements aren't convincing.

In any case, the Python maintainers have acknowledged the problems with super() in Python 2 and redesigned it for Python 3. The official docs (which @Howard.Swope linked to above) even points to a blog post which highlights the many benefits of super(). So, if you still truly believe that Python 3's super() is harmful, please talk to the Python creators, maintainers, and community. This forum is not an appropriate place for such discussions.

[Denni 0]

@JKSH I have actually posted it here some where and it can be found if you go searching for it on the internet but sure I have no problems with sharing it again for since its such a prolific issue out there due to so many misguided promoting it without understanding it I have it stored in a text file and posted in my classroom. The following is a compilation of various articles that I dug up on the internet so while I share their opinions the only opinion that is mine is the Conclusions. The facts on the other hand are the facts so read them and make your own decisions

How is super() used in PyQt

class Example(QWidget):
    def __init__(self):      
        super().__init__()

*** Versus ***

class Example(QWidget):
    def __init__(self):      
        QWidget.__init__(self)

---

What is gained by using this:

The differences start when you have multiple inheritance, the reason it was created. Then a chain of super() calls for this hierarchy:

          A
        /   \
       X     Y
        \   /
          Z

can easily proceed like this:

          A
            \
       X --- Y
        \   
          Z

without the need of X and Y knowing each other. This relates to the concept of method resolution order that allows a style of programming called "cooperative multiple inheritance" in the Python docs. Note however this does not work as nicely as is explained here due to other technical issues with it (aka the reason for some of the bugs).

It should however be noted that the need for this is extremely rare since most programs do not even implement multiple inheritance as most of the time a proper design simply avoids any need for it. Besides single inheritance easily makes enough spaghetti in its own right without creating major complexity by adding in multiple inheritance.

The other various claims I have found supporting the use of super() in python are the same reasons its used within the static languages C++ and Java however these languages do not have the issues that the dynamic Python language has when using this functionality. These being it simplifies creation which it actually does the opposite in Python making it more complex. It simplifies modifications of one's code, this is basically lazy coder thinking and further is not really true either once you take into account the issues using it creates. Their statement to this is it makes it simpler when you go changing your parent classes which to me means they have design issues as that ought to be pretty defined and not need to be changed much if at all. Further this could be more easily fixed by importing and changing the name with the "as" statement such that in your code it never changes even if it changes within the source library should that be the reason for it.

Now here is laziness taken to the extreme and part of the reason I chaff at these individuals: "...if you switch from QVBoxLayout to QHBoxLayout, you only have to change it in the class definition line, rather than in the init method as well." Seriously a simple copy/paste done twice and the explicit version is done without adding any additional issues to your code, how dang lazy can one get. Heck you all you really have to do is change the V to H a few times and your done. Really you are adding complexity for something this simple.

So those are the reasons for using super() or the pros per-sae so what are the cons well as I stated including super() into your code creates 4 issues that you must be aware of and code for along with this super() still has bugs (go check the current bug reports) within the world of python due to its incompatibility with a dynamic language.

It should be noted that within static languages C++ nor Java this feature works fine (aka no bugs) however due to the added complexity of trying to add this feature to a dynamic language (Python) it does have bugs. The key here being the ADDED COMPLEXITY. So by using super() you introduce these bugs (which may or may not cause your program issues) into your code. Further even if these bugs were to get fixed that does not guarantee you that there are no bugs because when you add something this complex to the code there are sometimes hidden little issues that happen that get missed -- and more importantly K.I.S.S. is always the way to go as much as possible.

So if you do use super(), here are some things you need to be aware of:

• You must use it consistently, and document that you use it, as it is now part of the external interface to your classes, like it or not.
• Never call super with anything but the exact arguments you received, unless you really know what you are doing and maybe not even then.
• When you use it on methods whose acceptable arguments can be altered on a subclass via addition of more optional arguments, always accept *args, **kw, and call super like
  super(MyClass, self).currentmethod(all-the-args-declared, *args, **kwargs).
  If you do not do this, forbid addition of optional arguments in sub-classes.
• Never use positional arguments in __init__ or __new__. Always use keyword args, and always call them as keywords, and always pass all keywords on to super().

Lastly super() violates the 'Explicit is better than Implicit' maxim of good coding practices. A maxim that has been proven time and time again to be an item of quality coding due to all the headaches it prevents.

So by adding super() you are now having to track four additional items that you would not have had to had you not used it. And you are actually gaining nothing of note by including it. So I see absolutely no reason to add something that increases complexity, adds bugs, and yet gains you basically nothing of note.

As a final note numerous quality coders know from experience that in python code, needing to define the same name method in two branches of an inheritance tree is exceedingly rare, with the exclusion of __init__. And, super() is useless for that if you need any kind of interoperability with existing python code. So we as a whole cannot envision any proper quality design where this functionality would actually ever be needed.

---

My Conclusion

The arguments for the use of super() are not compelling and in fact are a bit scary for in a nutshell it kind of says everyone else is using it and it makes code easier to write because you can over look those minute details. Which is a similar argument that was used for implementing Goto statements which has been determined to be universally a wrong thing to do. So since super() carries with it risks creating problematic code it is best to just create clean explicit code and my summation of the final statement against using super() is if you are implementing code that requires this functionality then you ought to go back to the design board and figure out what you are doing wrong. In essence, counter to the pros comment using super() actually makes your code more complicated rather than less complicated and its basically an unnecessary complication which is never a good thing.

P.S. I am aware that there might be a few other Pros that I did not list but most of them have the same basic theme -- here is a lazier way of doing this -- and use of it is rather minor compared to the bigger picture however if you want to list all of these I am sure you can find them as the proponents of this bad coding practice are much more vocal than those who know it to be bad. Keep in mind also that this actually helps keep us quality minded programmers employed as we often have to clean up the messes created by the lazy coders.