Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

Calling __init__() in QObject subclasses



  • @KeirRice said in 'PySide2.QtCore.Signal' object has no attribute 'emit':

    You also need to make sure that the init of the QObject is called. This is where pyside does the setup of the signals, trying to use the signal before setup wont work properly.

    @KeirRice are you still around? :)

    This answer is indeed correct for PySide2. However, I don't understand what you mean by "make sure that the __init__ of the QObject is called". I do not define any def __init__(self) method of my class someClass(QObject), and it works fine. Just deriving from QObject (or from any class) calls its __init__() automatically.

    The only reason you need one in your example is because you want to do some other work there (connecting the signal in your case, which most people will do in the outside world, not in class's constructor). And then of course, like any derived class with its own __init__, you must call super().__init__().

    I see nothing at all special about defining/calling __init__() for the signal definition class. Do you have any comment (if you still exist :) )?

    [Edit: Locked as toxic and unproductive ~kshegunov]


  • Banned

    @JonB said in 'PySide2.QtCore.Signal' object has no attribute 'emit':

    The only reason you need one in your example is because you want to do some other work there (connecting the signal in your case, which most people will do in the outside world, not in class's constructor). And then of course, like any derived class with its own __init__, you must call super().__init__().

    Okay going to address this here but this goes back to @KeirRice example code as well:

    Do not use super( ) unless you are fully aware of what 3 major issues you must code for in conjunction with using it and the actual rare issue that it is meant to solve. Further this rare issue is actually rare and unless you are doing some complicated inheritance you will most likely never run into that issue -- however the 3 major issues it creates by using it are much more likely to occur than the rare issue its meant to resolve

    Yes I know that everyone is using it because its super but what it really is that they do not say is its super bad and super lazy thinking because if you dig deep enough under the hood of the misinformation you will find the truth. And again unless you are doing some rather complicated inheritance you do not need super which by the way makes your code more complex and more dangerous than not using it. So once you understand it fully -- and I mean fully understand it -- because there are folks seemingly in the know that keep putting out garbage as to why its supposed to be so good but they never dive into why its so bad. Further this is an issue inside Python the original language that super came from does not have the issues that python does when using it and in that language it is super good
    --------------------------------------------------------------------------
    As to the problem with Signals and Slots I do believe @tham that those that have answered your question have given you the correct information and you should be trying to figure out what you are doing wrong rather than telling them they are wrong. Further yes it is much more straight forward to use Qt with C++ as that is its native language as you do not have the issue with the python wrappers that are applied to it -- however this also means you lose all the benefits of using python over C++. C++ is an object oriented language while Python is a function oriented language to totally different beasts. The progression of language types is as follows (if you were unaware) Linear Based (C) >> Objected Oriented (C++/C#) >> Function Oriented (Python) ... each of these has its strengths and its weaknesses the question you must ask yourself is what are you giving up by going down the tree of progress when going from Python down to C++ versus what you are gaining?

    Note it took me a while to figure out how to fully use Signals/Slots correctly and also to understand when to use them and when its not necessary to use them. They serve a purpose and are a tool but like any tool you need to understand it so you can use it correctly. I have bumped heads with numerous other programmers on using Signals/Slots as they feel it ought to be used everywhere -- but Signals/Slots like any tool has its pros/cons -- and using them everywhere is just wrong especially if by using them you unnecessarily add more complexity to your program than is needed without gaining any real benefit from using them.



  • @Denni-0
    The question has absolutely nothing to do with whether you use super().__init__() or baseClass.__init__(). Nothing to do with super(), irrelevant to the question, which is why that user says it's important "You also need to make sure that the __init__ of the QObject is called" in a class which defines a signal. That is the only question being asked.

    I am well aware of your opinion on super(), since you express it in nearly every post you make. And I don't agree with you, and nor do plenty of others.

    you should be trying to figure out what you are doing wrong rather than telling them they are wrong.

    Simply wrong. Did you read where I said

    This answer is indeed correct for PySide2.
    I do not define any def __init__(self) method of my class someClass(QObject), and it works fine.

    So it works fine without defining any __init__() method. And at no point did I say that poster was "wrong" in what he wrote, I merely asked him why he thinks it's important to do that. So don't tell me "I should be trying to figure out what you are doing wrong " when I'm not doing anything wrong.

    Nothing I have asked has anything to do with Python/PySide2 versus C++.


  • Banned

    @JonB I think you missed the point let me highlight the sentence for you:
    And then of course, like any derived class with its own init, you must call super().init().

    This was what I was responding to when I spoke about using super and if it had nothing to do with the question then why would you even bring it up other than to promote more misinformation.

    Further I am going to bring this up every time one of you misinformed state something that is absolutely wrong as the truth is within python you ought almost never call super().__init__() and instead use the original baseClass.__init__(self) instead.

    Also you exceedingly exaggerate because I do not mention this it in nearly every post I only mention it in posts where one of the misinformed chooses to post something using super and I do this so that newbies are not misguided by individuals like yourself who are unaware of the 3 major issues that using super in python creates nor perhaps even the reason why it was initially even brought over into python. So okay you disagree with me but I base my position on the full facts yours is based on those wonderful "alternate facts"

    Perhaps you meant to say in every post you put up because you choose to keep trying to misinform others about using super without fully understanding it yourself -- because frankly if you fully understood I cannot imagine you would even use it yourself


  • Banned

    Next I am not even sure why you are quoting a comment I made to tham as if I had made it to you? I think you got grouped into the "that those that have answered your question" category -- so again not seeing why you bring up any of that other stuff. I will just assume you mis-read my post and/or took the comment about super so deeply that you assumed the entire post was directed at you -- which it was not.

    Note I put a line in my original post to help you with the division in topics and to whom is being spoken to you are above line and tham is below the line



  • @Denni-0

    of you misinformed state something that is absolutely wrong as the truth is within python you ought almost never call super().__init__() and instead use the original baseClass.__init__(self) instead.

    I don't agree, and nor do millions(?) of other Python3 programmers. But we'll have to move on, because discussing it gets us nowhere.

    Let's ask this. Here are two definitions of a derived class:

    First:

    class DerivedClass(BaseClass):
        pass
    

    Second:

    class DerivedClass(BaseClass):
        def __init__(self):
            BaseClass.__init__(self)
    

    Imagine that's it. There is nothing else, no other stuff. For example, there is no multi-inheritance, else the code would show it. Just that code. Not something else. (Note I've used BaseClass.__init__(), not even super().__init__(), so we don't have to wonder about super()).

    The question is: do these two behave any differently than each other, just as they stand? I say/claim/think/suspect they do not behave differently. If you do not define any __init__() in a derived class, it calls the base class's __init__() automatically (can be verified in a debugger), so I claim there is no difference. If you think there is a difference (I don't know whether you do), can you supply some actual, concrete reference which says so and explains precisely what it is?

    That's is all my question really is.


  • Banned

    Without delving into the underlying wrapper that has been created by someone else I find the question rather moot as it is the same as doing the following

    QSomeObject.connection(function)
    
    def function():
    

    --vs--

    QSomeObject.connection(function)
    
    @Slot()
    def function():
    

    Is there a difference in these two implementations yes -- do you notice any when using code probably not but there is a difference and the explicit in this case is much better as it prevents potential issues from occurring which is often what generally happens when one chooses to use explicit versus lazy coding. So while your class without the __init__ might work fine under most situations it could just as easily glitch without one even being aware that it is doing so. This is why explicit is always better than implicit coding as it helps reduce the number of unexpected gothchas within your code.

    As for super in python I am going to guess there are not nearly a million misguided programmers out there that believe as you do but I will a test though there are quite a few but then at one time many scientific folk believed that the world was flat so just because you might have the majority on your side it does not mean that they are correct at all. Further I again challenge you to state the 3 issues you have to be aware of and code for when using super versus not using it and what is the original core purpose of super what is it that it was actually implemented to fix? You have never answered that nor even questioned it -- you just keep saying others believe it not to be so, to which I ask can you not think for yourself?



  • @Denni-0
    It's a very simple question. Nothing to do with slots, connections, potential issues, super, 3 issues, or anything else. Not to do with what one might or might not consider better style. There are no "underlying wrapper that has been created by someone else".

    Without answering about anything else, are you saying

    class DerivedClass(BaseClass):
        def __init__(self):
            BaseClass.__init__(self)
    

    behaves differently from

    class DerivedClass(BaseClass):
        pass
    

    ? I'd like to know. If so, could you provide a reference so I can read up. Thanks.


  • Banned

    I will tell you what once you answer my question about super I will consider looking into your question about this. Because personally I could careless about this as I plan to always do it explicitly regardless because by in far explicitly is safer and cleaner when it comes to coding every time.


  • Banned

    @JonB yeah did not figure you could answer that question because you simply do not know what it is you are playing with which will eventually cause you major issues while I and those I teach will move along smoothly because we do understand what we are doing and why.

    Now to help those that might have wondered about your question and to perhaps inform you, here is the answer to what I perceived as a troll question since it appeared to serve no other purpose and was completely out of context:

    @JonB said:

    It's a very simple question. Nothing to do with slots, connections, potential issues, super, 3 issues, or anything else. Not to do with what one might or might not consider better style. There are no "underlying wrapper that has been created by someone else".

    Without answering about anything else, are you saying

    class DerivedClass(BaseClass):
        def __init__(self):
            BaseClass.__init__(self)
    

    behaves differently from

    class DerivedClass(BaseClass):
        pass
    

    ? I'd like to know. If so, could you provide a reference so I can read up. Thanks.

    Okay as I believed and a little bit of research revealed that these 2 different QClass references (since you did not specify but because that had been the scope of the discussion) do indeed behave quite differently and not only that if the second is used you will be prone to encounter errors if your DerivedClass attempts to do anything but rename the QBaseClass and maybe even then. Basically in a nutshell, the second QClass is denoted as improper usage classing a QObject within Python and that should be enough in and of itself however there are a myriad of reasons why the second version should never be used. However as for references all I can say is learn to google as the answers are out there both for this question and the one I posed to you that you could not answer.

    Lastly if anyone seriously wants to know what the differences are between these two calls and why the second one is very problematic I would be more than happy to explain the nuts and bolts of how and why this is. Just let me know and I will create a separate thread covering this.



  • @Denni-0 said in 'PySide2.QtCore.Signal' object has no attribute 'emit':

    troll question

    I never ask "troll" questions. Life is too short.

    In my example I don't particularly intend BaseClass to be derived from QObject, else I would have stated that explicitly. Though it could be, if that makes any difference to the answer.

    I have since looked around and seen much code (both Qt and non-Qt) which does indeed not bother to declare an explicit __init__() constructor in a derived class if it does not need to do anything other than class the base class constructor. At the moment from reading around I am happy that the default behaviour of a derived class with no explicit __init__(), which is to call base class __init__() automatically, suffices. Unless you have a reference to the contrary?


  • Banned

    LOL Well @JonB there a more than references how about just basic coding fundamentals. Things you ought to be aware of if you are any kind of real programmer. So let us analyze this horrible position you have taken which is just as horribly misguided as the one you took on using super() both most likely due to your inability to sort truth from fiction. BTW if you had come to me respectfully with your question I would have been more than happy to have explained this to you in that manner but you chose to be basically disrespectful in your approach and the only reason I am responding at all is to help those you would otherwise horribly misguide since you have no clue what you are actually talking about but are acting like you got all the good answers which you have nothing but horribly misguided misinformation.

    So what is the actual difference (if any) between these two calls:

    class MyWidget(QWidget):
    --vs--

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

    Well first and foremost the latter one is explicit about what the programmer wants to happen and the former is simply sloppy lazy coding which is prone to have issues.

    Past that we run into basic inheritance rules because the only magic about the __init__ method (aka the classes initiator) is not how it is called but more when it is called. Basically, the standard object oriented lookup method resolution order is applied. If there is no standard __init__ declared in a class that inherits from another class then per object oriented inheritance rules it simply inherits the __init__ from the parent class. Thus even if the __init__ is never defined in a class, the default parent class object provides it. So okay so far but I am guessing that is as far as you read so let us continue and dig a bit deeper beyond the extreme surface layer

    Again we were talking QObjects (yeah I know troll questions tend to jump topics and yours went even further outside the topics boundaries). So dealing with the Qt Orientation of this Forum we then find that while this is the case there is a caveat to this within Python-Qt as it is stated that it is very important that one always remember to call the (in this case) QWidget.__init__(self) from inside the child class's constructor (__init__). For failing to do so can mean that the parent class is not properly instantiated which can in turn cause some very frustrating bugs.

    Also there is the issue with what happens to the reference to the child instance when we do the former (your poorly accept version), as we are making the assumption that this too is being handled some how by the parent constructor even though we are not passing it explicitly as we do in the latter case. So what happens does this get passed in implicitly or is this perhaps the cause for those very frustrating bugs that can occur by not doing it properly and explicitly much like using super creates issues if not handled properly which so many programmers (such as yourself) seem to be totally unaware of or they would be easily able to address the 3 issues (and thus easily state them) along with the only real reason super should ever be used (which means you should be able to easily state this if you had the knowledge of what you speak of -- which you obviously do not).

    Next what is this Python __init__() Function? Many misinformed individuals believe it is the objects constructor method. As explained below:

    Simple Object Oriented Information

    A constructor resembles an instance method, but it differs from a method in that it has no explicit return type, it is not implicitly inherited and it usually has different rules for scope modifiers. Constructors often have the same name as the declaring class. They have the task of initializing the object's data members and of establishing the invariant of the class, failing if the invariant is invalid. A properly written constructor leaves the resulting object in a valid state. Immutable objects must be initialized in a constructor
    --------------------
    So here we see what a constructor is which kind of sounds like the __init__() method as it is used to initialize the object's data, but __init__() is a special method which per its name initializes objects and it is immediately called when an object is created but this initialization method does not allocate memory which is something a constructor does. So what does allocate the memory and actually setup the instance aka what is are actual constructor?

    Well there is a hidden thing going on and it involves the creation of self, something that needs to get passed to this __init__() method and that occurs within the __new__() method which is the actual constructor of the class instance and gets called before the __init__() method which simply is used to finalize the construction of that instance.

    Things which are needed to be kept in mind about __new__():
    • It is always called before __init__()
    • The first argument passed in is the class itself

    class Point(ParentClass):
        def __new__(ClassInstance):
            print(ClassInstance)
    
            obj = ParentClass.__new__(ClassInstance)
    
            return obj
    
    Output>  <class '__main__.Point'>
    

    • It always returns a valid object. Not mandatory, but that is its whole point
    • It controls object creation. Which means, in an extreme case, one can return a completely different type of object at the end.

    Although in Python we use __init__ almost in the same sense as a C++/Java constructor while programming (to create members of a new class instance) , it is not really the same in how it works because Python is a dynamic language while C++/Java are static languages. This is the same base reason why super() works in C++/Java and does not work in python.

    Now one may/may not choose to call __init__ a constructor subjectively as there is no fixed scientific definition of what a constructor actually is but this would also be technically incorrect as well due to what OO states is supposed to be contained within the constructor.

    So the difference is when a C++/Java constructor is called, memory is allocated for the instance, which has memory for each of the members that it initializes. However in the case of Python, a blank object is created then __init__ is called. The __init__ method then dynamically initializes each member. Taking self as a parameter means the object has already been created before __init__ is called.

    So to give a more human analogy, a C++/Java constructor generates a three-ring-binder full of blank pages, while a python constructor first generates an empty three-ring-binder and then it adds pages into it one by one.

    So finally drilling back to Python the core of Python-Qt one can do this:

    class A:
        pass
    

    However this is extremely pointless, because without defining __init__ the instance of the class has no data associated with it and what you have is just a function assuming you provide some method within. But then you could have defined that function without the overhead of the class and had pretty much the same thing.

    So as can obviously be seen there is a lot more under the hood than you were apparently aware of and if you are still comfortable with your stance as being a good one then I feel for you because you simply cannot comprehend the basic coding principles of Object Oriented programming let alone Function Oriented programming and I would suggest you go back to linear coding as you will cause a lot less harm with your programs.



  • @Denni-0 said in 'PySide2.QtCore.Signal' object has no attribute 'emit':

    BTW if you had come to me respectfully with your question I would have been more than happy to have explained this to you in that manner but you chose to be basically disrespectful in your approach

    because you simply cannot comprehend the basic coding principles of Object Oriented programming let alone Function Oriented programming and I would suggest you go back to linear coding as you will cause a lot less harm with your programs.

    OK, if that's how you feel and speak let's call it a day. Nobody other than you speaks to people like this in this forum.


  • Banned

    Well @JonB that is actually as truthful as the rest of your claims (aka a total lie) as that is exactly how you spoke to me but using your own version of it of course and nothing I stated was a stretch beyond the actual truth but I imagine in this case the truth hurts a bit -- now if you were truly interested in wanting to be spoken to congenially then you ought to approach your audience congenially I would hope that you will learn from this but from your post I get the feeling you do not feel you have done anything wrong -- which sadly is how folks like you continue being abusive because you never stop to actually consider if you were or not and just assume not when the truth was/is you were.

    Note subtle abuse is just as bad as overt abuse -- so in short @JonB stop being abusive completely as masking it does not always keep it hidden to everyone

    Lastly when confronted with facts that blow your trolling claims completely out of the water I am not surprised at all that you have fallen back to trying to divert the issue away from your extremely faulty logic and totally misinformed claims

    However if you ever want to apologies for being a jerk I would be more than happy to lend you a respectful hand going forward but that is totally up to you and on you as I am sure I am not losing out on anything



  • @Denni-0
    I have been careful to be polite in everything I have ever posted in response to you, always saying you have your opinions and others have theirs. You are just rude and abusive. Nobody other than you accuses others of lying, trolling, or the endless stream of insults you throw in your responses. I guess in all my career I have never come across anyone like you in a professional or technical environment. I still remember the first post I saw from you where you announced that @Pablo-J-Rogina was a "troll" and you would have him banned. It's a shame you are allowed to do so.

    We have nothing more to say to each other.


  • Banned

    @JonB by your definition I am sure you believe you are not being snarky and abusive but gladly the world does not revolve around your opinions. Further you sure hate when someone reciprocates the same attitude you are using -- so careful are you to be polite dude you so miss that mark its pathetic -- I can simply state and have a record to prove it that I do not post in this manner to others who are not themselves being abusive in some way. Further while you have been fairly consistent I agree but you have been fairly consistent at not being polite -- further even worse you instruct newer programmers to follow extremely poor coding practices and are yourself not seemingly even interested in learning to be a better programmer just a snarky one. Note I am not accusing I am flat out stating fact -- you have both been lying and trolling -- but only because that is the definition of what you have been doing -- granted you do try to make it more subtle but you can put sugar on garbage and call it something else but it is still garbage.

    Oh and by the way that was not my first post maybe the first one you remember, but yes he at the time was trolling just like you have been doing -- again calling it something else does not make it so the truly sad things is that you are allowed to not only get away with trolling (as you are continuing to do) but also with putting forth false information as if it were truth and then not being able to back it up with any facts -- just more trolling in order to try and cover up the fact that you seem to know next to nothing about real programming. Oh and in my career (probably because its been much more extensive then yours) I have come across individuals like you and they are almost always in some situation where they abusiveness is overlooked and they are totally clueless that they are producing garbage code until they get discovered and subsequently fired -- assuming they actually even have a programming job to begin with.

    And you cannot tell me that I have nothing more to say just because you deem it so -- I will stop posting the moment that you no longer make a post otherwise I will respond to your continued trolling until either you give up or the moderators step in and put an end to this nonsense you started and have not given up on. As I will not be bullied by you in any way shape or form -- mister you are not at all polite not matter what you claim.

    And again if you never talk to me again that is a win-win in my book because frankly you have nothing of any value to offer.


  • Qt Champions 2017

    @JonB said in Calling __init__() in QObject subclasses:

    I guess in all my career I have never come across anyone like you in a professional or technical environment.

    I have. I suppose you've just occupied a less hostile time and place in the universe.

    I still remember the first post I saw from you where you announced that @Pablo-J-Rogina was a "troll" and you would have him banned.

    Heh, that's actually rather funny.

    It's a shame you are allowed to do so.

    Personally, I'm very lenient, less personally - willfully treading on thin ice is going to get you into the freezing water, sooner or later.



  • @kshegunov said in Calling __init__() in QObject subclasses:

    get you into the freezing water

    it is beneficial for your health


  • Qt Champions 2017

    @LeLev said in Calling __init__() in QObject subclasses:

    it is beneficial for your health

    Ordinarily I'd agree, but the deadly sniffles is afoot, so I'd advise against it.


  • Moderators

    @JonB said in Calling __init__() in QObject subclasses:

    I don't understand what you mean by "make sure that the __init__ of the QObject is called". I do not define any def __init__(self) method of my class someClass(QObject), and it works fine. Just deriving from QObject (or from any class) calls its __init__() automatically.

    While I don't have experience with PySide, I read @KeirRice's comment as saying: "IF you implement a custom __init__() method, THEN remember to explicitly call the base implementation of __init__()."

    Does that sound right to you?

    @kshegunov said in Calling __init__() in QObject subclasses:

    the deadly sniffles

    That's the first time I've heard it called that. It's a disturbingly cute name.


  • Banned

    @kshegunov the interesting thing I found is that JonB did not feel he was doing anything impolite as he feels every unrelated completely off topic manipulative comment he has made was simply him being polite. Which is ironic because that by nature is not a polite thing to do however I have no problems with giving back what I am given which is to say try to bully me and I get right in your grill -- now however actually be polite and I am overly friendly willing to help to the best of my ability I would also state so far in the numerous posts I have responded to only Pablo-J-Rogina and JonB have done what they have done -- not sure what to call it because while it fits the definition (from what I understand) of trolling on the low end the moderators do not feel it was. I am currently trying to find out what their definition of trolling is.

    @JKSH I believe JonB was referencing his extremely bad practice for not implementing an __init__() at all because he is under the disillusionment that because he has not experienced any issues that he noticed as of yet that doing so was a perfectly fine practice to follow much like he feels using super() is perfectly safe to do in Python both of which are completely wrong but they did not seem interested in the facts about it either and they just wanted to stand firmly on their woefully wrong opinion and try to misguide other newer programs to adopt their very bad programming practices


  • Qt Champions 2017

    @Denni-0 said in Calling __init__() in QObject subclasses:

    @kshegunov the interesting thing I found is that JonB did not feel he was doing anything impolite as he feels every unrelated completely off topic manipulative comment he has made was simply him being polite.

    What he feels or doesn't feel is beside the point. He asked an acceptable question, and even if you think it may've been manipulative, well sorry, you're just gonna have to eat it.

    Which is ironic because that by nature is not a polite thing to do however I have no problems with giving back what I am given which is to say try to bully me and I get right in your grill

    I don't grill. I have a very thick skin that's been growing thicker by merit of my living in eastern Europe. I don't care about political correctness, nor do I employ it, nor do I agree with it. I call it as I see it, if you don't like that then I suggest refraining from talking to me. Don't try to test the patience of the moderators group, we are decent enough bunch and allow a lot of freedom, but that doesn't mean disruptive aggressive behaviour is going to be tolerated for too long a time. This is not a discussion, mind you, I'm telling you how things are.

    I am currently trying to find out what their definition of trolling is.

    Trying to hijack the technical discussion on multiple occasions by arguing moderators' decisions is one form of trolling. Everyone is entitled to their opinion, but that doesn't mean everyone else is entitled to listening to their opinion, like with the "entitled" tone in the second part of your post. If you think this is some kind of a democracy where your opinion of what's trolling weighs more than say @SGaist's, then I must assure you you're sorely mistaken. Blatantly disrespectful tone and going around telling everybody you're smart and they're dumb doesn't fly well, neither in earning respect, nor in soliciting support for your point.


  • Banned

    @kshegunov he asked a completely off topic question and imo for reasons for his own gain -- below is the accepted definition of what a Troll is and thus what trolling is -- so not my definition of it but the general one that many seem to overlook and/or forget. And please do not take my word for -- feel free to research it yourself as that is not an in-depth definition and I am sure there is more that could be added to it.

    A Troll is a person who distracts and/or sows discord or simply disrupts a discussion by posting inflammatory, digressive, extraneous, or off-topic messages in an online community with the intent of provoking readers into displaying emotional responses or causing the current discussion to become derailed, whether for the their mere amusement, for specific gain, just because they can, or because they just unwittingly wanted to. This often starts quarrels and/or upsets other people within the medium.

    Inflammatory: Intended to arouse angry or violent feelings

    Digressive: Departing from the subject matter being discussed

    Extraneous: Irrelevant or unrelated to the subject

    Off-Topic: Not relevant to the subject under discussion

    @kshegunov said in Calling __init__() in QObject subclasses:

    Trying to hijack the technical discussion on multiple occasions by arguing moderators' decisions is one form of trolling.

    @kshegunov said in Calling __init__() in QObject subclasses:

    I have. I suppose you've just occupied a less hostile time and place in the universe.

    Heh, that's actually rather funny.

    Personally, I'm very lenient, less personally - willfully treading on thin ice is going to get you into the freezing water, sooner or later.

    Yeah and your post was highly technical and spot on the original topic which is Calling init() in QObject subclasses --- NOT Best not to point fingers when you are extremely guilty yourself. Further its an extreme exaggeration "on multiple occasions?" or your math is really bad


  • Qt Champions 2017

    @Denni-0 said in Calling __init__() in QObject subclasses:

    Yeah and your post was highly technical and spot on the original topic which is Calling init() in QObject subclasses --- NOT Best not to point fingers when you are extremely guilty yourself. Further its an extreme exaggeration "on multiple occasions?" or your math is really bad

    Are we arguing? I told you already, this is not a discussion.


  • Banned

    No not arguing at all -- just stating the facts -- okay so you have ended this thread then? -- Also I am assuming by your statements that you have made earlier that you have moderator power otherwise you would not be so abusive yourself? Again not arguing just stating the facts.


  • Lifetime Qt Champion

    @Denni-0
    Since we are talking facts.
    Im the most friendly mod here and frankly, you are the first troll-like person i have seen here.

    I understand you feel deeply about__INIT__ but you resort to name-calling and aggressive behavior
    and insist that our long term users are trolling.

    So can you please dial it down a notch?


  • Qt Champions 2017

    @Denni-0 said in Calling __init__() in QObject subclasses:

    okay so you have ended this thread then?

    Yes, metaphorically and literally.

    Also I am assuming by your statements that you have made earlier that you have moderator power otherwise you would not be so abusive yourself?

    When you assume ... and you know the rest. I've openly said already I am a moderator.


Log in to reply