Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. Language Bindings
  4. Python/PyQt heap, stack and deletion
Forum Updated to NodeBB v4.3 + New Features

Python/PyQt heap, stack and deletion

Scheduled Pinned Locked Moved Solved Language Bindings
7 Posts 2 Posters 2.2k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • J Online
    J Online
    JonB
    wrote on 14 Nov 2017, 09:37 last edited by JonB
    #1

    @jsulm
    In https://forum.qt.io/topic/85015/why-qthreadpool-do-not-clear-its-queue/2 @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?

    J 1 Reply Last reply 14 Nov 2017, 11:32
    0
    • J JonB
      14 Nov 2017, 09:37

      @jsulm
      In https://forum.qt.io/topic/85015/why-qthreadpool-do-not-clear-its-queue/2 @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?

      J Offline
      J Offline
      jsulm
      Lifetime Qt Champion
      wrote on 14 Nov 2017, 11:32 last edited by jsulm
      #2

      @JNBarchan

      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)?

      https://forum.qt.io/topic/113070/qt-code-of-conduct

      J 1 Reply Last reply 14 Nov 2017, 11:42
      0
      • J jsulm
        14 Nov 2017, 11:32

        @JNBarchan

        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)?

        J Online
        J Online
        JonB
        wrote on 14 Nov 2017, 11:42 last edited by JonB
        #3

        @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....

        J 1 Reply Last reply 14 Nov 2017, 11:45
        0
        • J JonB
          14 Nov 2017, 11:42

          @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....

          J Offline
          J Offline
          jsulm
          Lifetime Qt Champion
          wrote on 14 Nov 2017, 11:45 last edited by
          #4

          @JNBarchan Yes, objects are heap allocated in Python

          https://forum.qt.io/topic/113070/qt-code-of-conduct

          J 1 Reply Last reply 14 Nov 2017, 11:47
          0
          • J jsulm
            14 Nov 2017, 11:45

            @JNBarchan Yes, objects are heap allocated in Python

            J Online
            J Online
            JonB
            wrote on 14 Nov 2017, 11:47 last edited by JonB
            #5

            @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.

            J 1 Reply Last reply 14 Nov 2017, 11:52
            0
            • J JonB
              14 Nov 2017, 11:47

              @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.

              J Offline
              J Offline
              jsulm
              Lifetime Qt Champion
              wrote on 14 Nov 2017, 11:52 last edited by
              #6

              @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.

              https://forum.qt.io/topic/113070/qt-code-of-conduct

              J 1 Reply Last reply 14 Nov 2017, 11:59
              0
              • J jsulm
                14 Nov 2017, 11:52

                @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.

                J Online
                J Online
                JonB
                wrote on 14 Nov 2017, 11:59 last edited by JonB
                #7

                @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.

                1 Reply Last reply
                0

                1/7

                14 Nov 2017, 09:37

                • Login

                • Login or register to search.
                1 out of 7
                • First post
                  1/7
                  Last post
                0
                • Categories
                • Recent
                • Tags
                • Popular
                • Users
                • Groups
                • Search
                • Get Qt Extensions
                • Unsolved