[PyQt] QML, pyqtSlot and ownership

Phil Thompson phil at riverbankcomputing.com
Mon Jul 14 13:39:17 BST 2014


On 14/07/2014 12:59 pm, Nenad Ognjanovic wrote:
> Hello,
> I'd be very grateful if someone could confirm whether the solution to 
> the
> following two scenarios is valid:
> 
> I'd like to be able to call a pyqtSlot from QML, have the slot 
> instantiate
> and return a QObject, and have the QML take over the ownership of the
> object, without having to keep an explicit reference to the object on 
> the
> python side. Without explicitly using sip.transferto (as suggested in 
> this
> stackoverflow answer http://stackoverflow.com/a/24696295/858766 - the
> question was posted by me, please go through it if you have time), the
> object is garbage collected before it even reaches the QML side.
> Is using sip.transferto the correct approach here?
> 
> Additionally, there's a similar problem when the situation is reversed. 
> If
> I expose a class Dummy via qmlRegisterType and then instantiate it in 
> QML
> using Dummy {} (e.g. as a ListView delegate), a segfault will occur as 
> soon
> as the delegate gets out of ListView visible area and gets destroyed. 
> In
> this case I can add sip.transferto in the constructor but it doesn't 
> seem
> right, and it also causes the process to not quit after the event loop
> exits. Should I transfer the ownership back?
> Is sip.transferto even something a PyQt user should be using and be 
> aware
> of?
> 
> In both cases I don't see the destructors being triggered (by the fact 
> that
> there's no print output from the overridden __del__ and connected 
> destroyed
> signal handler), which contributes to my concern about the approach.

How would it work in C++?

In other words, is the PyQt behaviour correct and in C++ you rely on 
memory leaks (ie. the object existing without there being a reference to 
it)?

Or is there a PyQt ownership bug?

Phil


More information about the PyQt mailing list