[PyQt] Guaranteed avoidance of C++ destructor call

[Phil Thompson]

On Thu, 30 May 2013 23:27:04 +0100 (BST), John Lee <jjl at pobox.com> wrote:
> On Thu, 30 May 2013, Phil Thompson wrote:
> 
>> On Thu, 30 May 2013 22:49:24 +0100 (BST), John Lee <jjl at pobox.com>
wrote:
>>> Hi
>>>
>>> Is it possible to guarantee that a C++ destructor of a QObject wrapped
>>> by
>>> PyQt is never called?
> [...]
>>> If I can't guarantee that from PyQt, can I write a simple sip wrapper
>>> that
>>> will achieve the same end, without copying and pasting the Qt code?
>>
>> sip.setdestroyonexit() might do what you want.
> 
> Thanks, that sounds promising.  It does trigger some followup questions:
> 
> 
> If I call sip.setdestroyonexit(False) before I construct any QProcess 
> Python instances, can ~QProcess still be called for any reason, even if
I 
> ensure that:
> 
> 1. no Qt code deletes the C++ object, and
> 
> 2. my code does not call sip.delete(), and
> 
> 3. I create a module-global reference (my module) to the wrapping 
> QtCore.QProcess Python instance which I never explicitly unbind (but for

> all I know might get unbound by some part of the PyQt/sip/Python
shutdown 
> process)?

I would be surprised if the dtor was called in those circumstances.

> Other than the usual QObject parent/child hierarchy, are there any cases

> where Qt deletes things, that might surprise me?

Possible but unlikely.

> Since setdestroyonexit affects all cleanup and not only that of
QProcess: 
> Are there other notable side effects that you or others know of that I 
> might notice / be surprised by from calling sip.setdestroyonexit(False),

> as a result of the lack of the usual cleanup associated with particular
Qt 
> classses?  In other words, what cases are known / can be guessed at
where 
> my program might start causing a leak of OS resources like temporary 
> files, or badly terminated network connections, etc?

Calling it (which PyQt5 does automatically) makes a Python application
behave like a C++ one. So, potentially, it would suffer from the same
things - which of course would be application bugs.

Phil