Python Forum
A Simple PyQt5 Class
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
A Simple PyQt5 Class
#11
There is nothing wrong in using super(). Its usage is very well explained by the official documentation. If it led to bad code, it would have been removed from the language long ago. The discussion by Raymond Hettinger can be taken as a guide to solve difficult corner cases that may occur with super(), but in most cases, its use is rather straightforward.

When super was first introduced into python, it was not as ergonomic as it is today and that generated some arguments but all this is far behind us.
#12
Okay @Gribouillis while it is true that super() has been adopted as a go to practice it is kind of like using a spade or perhaps a shovel to dig a post hole rather than using a tool called a post-hole digger. Sure you can dig a post hole with a spade/shovel but frankly those are poor tools for that job. Much like you can use super(MyWidet, self).__init__() but you can just as easily and with less complexity and less issues use QWidget().__init__(self) and this latter version is the post-hole digger and the former version is your spade/shovel implementation (aka poor coding).

Oh but there is nothing wrong with using super( ) you claim -- or -- well there were issues but that is all water under the bridge even though nothing really has been done about the issues you should deal with (which most do not even know about) when you do use it. So let's fight this fire with your mechanism of quoting others because apparently thinking for oneself is not what one should do. This article covers some of the problems Python's Super is nifty, but you can't use it. Further there are several other articles out there that speak to why super( ) was created and what the pitfalls are to using it. Perhaps you all should do some thorough research on it. Now is it still a viable tool yes it is still a spade and it is still good for doing what one is supposed to do with a spade. It is just not a universal tool that you should be using universally as many have been doing. It has a purpose and should only be used for that rather rare (in this case) purpose and nothing more.

However let us examine the two methodologies and ask why is super( ) used in python-qt or python for that matter.
class MyWidget(QWidget):
    def __init__(self):      
        super(MyWidget, self).__init__()
*** Versus ***
class Example(QWidget):
    def __init__(self):      
        QWidget.__init__(self)
Soo, how are these two different? If you have simple inheritance (perhaps not counting "mixins"), then there is no difference in behavior. Although a cosmetic difference does remain- further you do not need to name your base class again - but you do have to name the same class again. Thus you save nothing and there is no benefit.

The differences on the other hand starts when you have multiple inheritances. Then a chain of super() calls for this hierarchy:
          A
        /   \
       X     Y
        \   /
          Z
can easily proceed like this through super() calls:
          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.

If there is a method Foo and implementations in X and Y of that method build upon A's implementation, then Z is easily able to rely on both X and Y without them knowing even about each other. This, however, has an important precondition: Foo has the same (or at least [compatible]) signature in every class, as specified by A's interface where it is initially defined.

The __init__ method is special: technically it works in exactly the same way with super, but! (more often than not) for sub-classes it has a totally different signature. If the subclass' __init__ looks different, then super will not give you anything over explicit base call because you are not able to use cooperative multitasking anyway.

Note: Python is very atypical in this respect: in most OO languages constructors belong to the class, rather than the instances; in other words most languages rely on their equivalents of __new__ and do not have __init__ at all.

Note 2: I have never seen any real code that would rely on cooperative multiple inheritance. Since single inheritance easily makes enough spaghetti in its own right.

However, for some reason using super() is deemed as simplifying code when the fact is you are adding another layer of complexity without actually having any good reason to add that extra layer of complexity as under most cases you gain nothing but more complexity. Further while the defenders of using super() believe the debate to be over, it is not. Just those that have objected to it have simply decided its not worth wasting their time since Lemmings will be Lemmings let them jump off that cliff if they want to.

However if you insist on using super(), here are some best practices when using it and keep in mind you do not need these if you do not use super() and use the normal method instead. Also keep in mind that most folks that use super() do not communicate these issues when they share their rather poor coded examples because they either do not know themselves or worse do not care
  • Use it consistently, and document that you use it, as it is part of the external interface for your class, like it or not.
  • Never call super with anything but the exact arguments you received, unless you really know what you are doing.
  • 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(alltheargsideclared, *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.

Finally as stated by others who do not agree with this push for complexity: From our experience in python code (and thus by default python-qt 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. Thus we cannot envision any implementation where this functionality would actually be needed unless you have done something really wrong in your code design.

P.S. BTW there is still at least one a known bug in Python in regards to super() and its property inheritance behavior which of course effects python-qt as well and there could be more.

P.S.S. Do not take me wrong I am the first to admit that I do not know it all -- BUT if you can actually solidly refute the information I have just provided and using facts denote where my conclusion is wrong -- then I have no problems with posting an apology and adopting a better technique but as for right now all the facts that I found scream your position is in the wrong.
#13
Doesn't Raymond Hettinger's paper give the cure for the troubles that you had with super()? He gives a series of practical advices to use it consistently. Also multiple inheritance is not that prevalent in most programs, which reduces the potential issues.

If I had to give "expert" advice, I wouldn't say dont use super, I would say don't use multiple inheritance!
#14
Really you did not read what I just posted? I mean actually NO that article does not cure the troubles because the real trouble with using super() is you are adding additional complexity, additional issues, and additional bugs that you would not have if you had instead used the explicit method of referencing the object as it was meant to be referenced. Heck even the first example your toted author gives is a gain nothing example so it ends up being a lose-lose scenario. This whole lets make it more complex than it needs to be is what makes it a bad coding practice. Further your so beloved author does not even use the case that is getting so abused within any of their examples and perhaps this is because they too recognize the inherent issue for using it for what its so being abused for.

So to your advice I would then reply that it is not expert advice in anyway, shape, of form. Basically anytime you increase complexity for absolutely no reason you are by no means an expert just another wanna-be trying to make themselves look important. Kind of like someone using big words they have no real idea what they mean but neither does their audience so it makes them seem impressive but no one understands a thing they said including them self.

K.I.S.S. < That is the motto every programmer should adopt -- Keep It Simple and Smart otherwise you M.I.C.C. (pronounced Miss) < Make It Complex and Crappy

So basically: You Kiss It or You Miss It -- it is your choice, Still I guess you all keep me gainfully employed because I am often and frequently called in to fix the messes the MICCers create
#15
You didn't take the hint about goodbye Denni,so fill us in of your list over "very bad forums".
So this Thread is closed and your goodbye is now permanent on this forum,
good luck with other stuff as none of that will be here as a post or thread.
#16
Just to be clear, if Dennis wanted to have a reasonable discussion about this, he could have started a thread. Perhaps he could convince the forum of his view, and we'd start it as a best-practice. Instead, Dennis tried to hijack multiple threads to push his opinion as if it were fact. Claiming something as a best-practice when no one else agrees with you is... short-sighted, at best. Obviously, if Dennis is right, we've been robbed of knowing that fact by their poor inability to communicate it.
iMuny likes this post


Possibly Related Threads…
Thread Author Replies Views Last Post
  help needed running a simple function in pyqt5 diodes 27 8,166 Jan-24-2023, 12:19 PM
Last Post: GetOnData
  Huge code problems (buttons(PyQt5),PyQt5 Threads, Windows etc) ZenWoR 0 2,785 Apr-06-2019, 11:15 PM
Last Post: ZenWoR

Forum Jump:

User Panel Messages

Announcements
Announcement #1 8/1/2020
Announcement #2 8/2/2020
Announcement #3 8/6/2020