[PyQt] About QTimer and QThread and some general question

[catlessness]

1. if the interval of a QTimer is very small that not enough to let the slot function finish before timeout. What will happen? will QTimer wait for the function to finish before starting it again? Or it'll terminate the function and start again?

timer=QTimer(interval=1)
timer.timeout.connect(func)
timer.start()
def func():
#this function need more than 1 ms

2. if a child thread emits a signal to ask the main thread to do a function, will the child thread wait till the function in the main thread is done?

class A():
    def main(self):
        self.b=B()
        self.b.sig.connect(self.func)
        self.b.start()
    def func(self):
#some function

###
        
class B(QThread):
    sig=pyqtSignal()
    def run(self):
        self.sig.emit()
#will it wait here? Or it'll print the following text immediately?
        print('A.func() is finished')
       

3. When instantiating a subwindow, do you usually use subwin=Subwin() or self.subwin=Subwin()?

4. is it ok to pass 'self' around? for example, pass self to the subwindow or pass self to a child thread so that they can control the instantiated root class

[deanhystad]

Q1 and Q2: You should write some test code to answer your own questions.

Q3: What is a Subwin? Save values in instance variables if you need to use them later. Save values to function/method variables if you only need a reference for the duration of the function.

Q4: self is the object ID of the instance. The code that created the object already knows the value of self. It is not a big secret.

I don't know that I like the sound of "they can control the instantiated root class". Maybe I don't like it because I don't know what it means. What is "root class"? Why are you talking about classes at all? self is an instance, not a class. Maybe I don't like it because it stinks of dependency inversion.

Let's say you have class A that creates an instance of class B. Even though A depends on B, this is an acceptable dependency because A created B for some purpose, and it must know how B works to do the work it is supposed to do. Your program knows how ints work. It knows how to make an int object and how to add int objects. Your program is dependent on class Int, but that is just fine.

If A passes self to B, and B uses the reference of A to do something, B is now dependent on how A works. Changes to A might break B if B depends on the part of A that changed. This is called a "dependency inversion" and it is a bane of good software design. This would be like Int having to know something about the programs that use ints. This would limit Int's usefulness and you would have to review any changes to a program that uses Ints to verify that the changes don't break Int.

Sometimes priority inversion is OK. In a GUI a window will pass "self" to widgets it creates. This works because there are only so many things that can be the parent of a widget, and widgets know what they can do with those things. But even in the GUI world a button widget does not have to know what methods are available from the parent window, other than the ones defined by the limited API. A button does not automatically bind a button press to some method of the parent. Instead the button provides an API for binding the method/function, and the creator of the button is responsible for doing the binding.

So is it Ok to pass self around? Yes and no. Pass self if you need to, but limit the interaction between objects as much as possible. The more you can limit dependency, and in particular dependency inversion, the easier it will be for you to maintain your code.