text: Important: Please read the Qt Code of Conduct -
  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:
  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?
  In Python you must go
  w = QWidget()(note that there is no explicit
  newoperator), and that must be allocating on the heap?
  Since there is no
  newoperator, there is correspondingly no
  deleteoperator. 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)?
  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?
  - jsulm Lifetime Qt Champion last edited by jsulm
  @JNBarchan
  - I think Python allocates local variables on the stack:
  def fun(): a = 1 # This should be on the stack
  I think so ,yes
  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.
  .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
  newon 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....
  - jsulm Lifetime Qt Champion last edited by
  @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.
  - jsulm Lifetime Qt Champion last edited by
  @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.