Python/PyQt heap, stack and deletion

  • @jsulm
    In @jsulm wrote:

    Why do you allocate myThread on the heap? Allocate it on the stack. You also should delete all myRunnable instances you created when they are not needed anymore.

    I am seeing a fair number of answers referring to the heap, stack and deletion. It seems to me this can only apply to C++, and I wish to just verify my understanding of Python/PyQt behaviour for sure going forward:

    1. I believe Python/PyQt cannot allocate anything on the stack ("local variables" in C++). There is no such thing as a "stack [Qt] object" in Python?

    2. In Python you must go w = QWidget() (note that there is no explicit new operator), and that must be allocating on the heap?

    3. Since there is no new operator, there is correspondingly no delete operator. My understanding is that Python reference-counts, and the object will be implicitly deleted when (there are no other references and) the "variable" goes out of scope (don't know if it scopes inside, say, a nested if-block or just to the function as a whole)?

    4. In C#/.NET, which also reference-counts, objects which require "clean up of resources" usually have a common Dispose() method, which you can choose to call explicitly rather than waiting for objects to go out of scope at some unknown future time. I do not see that Qt objects offer an equivalent such function, and so I have no choice but to wait for out-of-scope-ness?

  • Moderators


    1. I think Python allocates local variables on the stack:
    def fun():
        a = 1 # This should be on the stack
    1. I think so ,yes

    2. Yes, Python has a garbage collector. Scope is still valid in Python - you can easily test that - just write a class with a destructor and create an instance in a scope and see when the destructor is called.

    3. .Net has a garbage collector, yes. But I disagree with this: "objects to go out of scope at some unknown future time". Actually scope defines pretty clear when it will go out of scope. Nothing unknown here and way better when garbage collector + Dispose() - do you know when garbage collector will free the memory? When do you call Dispose() and why if stack allocation can take care? And it is usually much easier and more safe to use scopes with stack allocation. It is very easy to forget to free memory allocated on the heap. Memory allocated on the stack is freed as soon as the variable goes out of scope.
      "I do not see that Qt objects offer an equivalent such function" - why should Qt reinvent the wheel (C++ "delete" operator in this case)?

  • @jsulm
    I believe you missing the point about Python stack/heap variables. You use the example of an integer, which will be on the stack. But that's why I wrote [no such thing as a] "stack [Qt] object". I assume when allocating a non-simple-value-type object (e.g. w = QWidget()) it's a new on the heap. That's certainly what C# does :) Remember, Python has no "typed variables", so I don't see how the caller would even know what/how much to allocate on its stack, it just takes the "unknown" object returned from a function call and runs with it! So I'm still assuming that in Python all my Qt objects will be heaped....

  • Moderators

    @JNBarchan Yes, objects are heap allocated in Python

  • @jsulm
    Yes, I think so, so I believe your comments elsewhere about "allocating Qt objects on the stack" apply to C++ but not Python. Not complaining that you do so, I understand most people use Qt from C++, just need to verify the Python situation.

  • Moderators

    @JNBarchan Well, if the topic was C++ then my comment was valid. I do not want to talk about all other languages which you can use with Qt, it would be simply off-topic and confusing.

  • @jsulm
    As I said, I totally understand that, I was not complaining, in this question I was just trying to clarify the Python behaviour so that I may bear it in mind when I read answers elsewhere. Which I believe we have now indeed covered here, thank you.

Log in to reply

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.