causes self to be owned by Qt instead of PyQt ???

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

causes self to be owned by Qt instead of PyQt ???

iMath
In the QObject.__init__(self, Parent=None) documentation it states:

The parent argument, if not None, causes self to be owned by Qt instead of PyQt.

What does it mean to be owned by Qt instead of PyQt? Does this have effects on behavior that I should be aware of when developing a PyQt application?




_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: causes self to be owned by Qt instead of PyQt ???

Phil Thompson-5
On 30/03/2015 11:15 am, redstone-cold wrote:
> In the QObject.__init__(self, Parent=None) documentation it states:
>
> The parent argument, if not None, causes self to be owned by Qt instead
> of PyQt.
>
> What does it mean to be owned by Qt instead of PyQt? Does this have
> effects on behavior that I should be aware of when developing a PyQt
> application?

It means that Qt will call the dtor of the C++ instance when necessary
and it may still exist even if the Python object that wraps it is
garbage collected. Generally you don't need to worry about it.

Phil
_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: causes self to be owned by Qt instead of PyQt ???

iMath
1)"The parent argument, if not None, causes self to be owned by Qt instead of PyQt", does owned by PyQt also mean the object owned by Python ?
If it is true ,then another question below 

2)In the doc of sip.setdestroyonexit(destroy) says, "Calling this function with a value of False disables the automatic destruction of C++ instances and C structures(owned by Python)." ,then which is responsible for destroying these C++ instances and C structures? the dtor of them ?

3)In the doc of sip.setdestroyonexit(destroy) says,"When the Python interpreter exits it garbage collects those objects that it can. This means that any corresponding C++ instances and C structures owned by Python are destroyed. Unfortunately this happens in an unpredictable order and so can cause memory faults within the wrapped library. " 

"since Python does not guarantee that objects will be deleted in a specific order when it exits. On the other hand, when Qt deletes an object, it always tries to delete all its children as well, which will normally ensure that objects get deleted in the right order. This is especially important when Qt takes ownership of an object, because you could end up in a situation where an attempt is made to delete the object twice (which will result in a crash)." quoted from here http://stackoverflow.com/questions/27131294/error-qobjectstarttimer-qtimer-can-only-be-used-with-threads-started-with-qt

Since Qt ensure that objects get deleted in the right order, so is it better to let the parent argument not be None, thus causes self to be owned by Qt instead of PyQt? or just set sip.setdestroyonexit(False) ?

4) When I Wrapped the if __name__ == '__main__': part in a function main(),the issue went away ,can you explain why ? changed version https://bpaste.net/show/36c594a1c82e




在2015年03月30 18时32分, "Phil Thompson"<[hidden email]>写道:

On 30/03/2015 11:15 am, redstone-cold wrote:
> In the QObject.__init__(self, Parent=None) documentation it states:
>
> The parent argument, if not None, causes self to be owned by Qt instead
> of PyQt.
>
> What does it mean to be owned by Qt instead of PyQt? Does this have
> effects on behavior that I should be aware of when developing a PyQt
> application?

It means that Qt will call the dtor of the C++ instance when necessary
and it may still exist even if the Python object that wraps it is
garbage collected. Generally you don't need to worry about it.

Phil
_______________________________________________
PyQt mailing list    [hidden email]



_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: causes self to be owned by Qt instead of PyQt ???

Florian Bruhin
Hi,

(note: I'm not 100% sure about my answers - so if I'm wrong somewhere,
someone please correct me!)

* redstone-cold <[hidden email]> [2015-04-01 14:32:19 +0800]:
> How do you know the crash happens in QObject::thread()?

(I got this off-list, but I'm answering here as well)

There are two approaches to get more info (i.e. a C++ stacktrace) when
debugging segfaults:

- Prepending the commandline with 'catchsegv'. This is very easy, but
  will print mangled C++ symbols like _ZNK7QObject6threadEv which you
  need to decode via c++filt or http://demangler.com/

- Running it inside gdb, usually with something like:

  gdb /usr/bin/python3.4 -ex run

  And then using 'bt' to get a backtrace when the segfault happens.

> sip.setdestroyonexit(False) is the default with PyQt5 ?How do you
> know this ?

I don't know where I originally picked it up, but it's listed here:

http://pyqt.sourceforge.net/Docs/PyQt5/pyqt4_differences.html#object-destruction-on-exit

> 1)"The parent argument, if not None, causes self to be owned by Qt instead of PyQt", does owned by PyQt also mean the object owned by Python ?
> If it is true ,then another question below

Yes - something is either owned by Python/PyQt, or by C++/Qt.

> 2)In the doc of sip.setdestroyonexit(destroy) says, "Calling this function with a value of False disables the automatic destruction of C++ instances and C structures(owned by Python)." ,then which is responsible for destroying these C++ instances and C structures? the dtor of them ?

The destructors will never be called in that case - which *usually*
isn't an issue, because the application is exiting anyways.

> 3)In the doc of sip.setdestroyonexit(destroy) says,"When the Python interpreter exits it garbage collects those objects that it can. This means that any corresponding C++ instances and C structures owned by Python are destroyed. Unfortunately this happens in an unpredictable order and so can cause memory faults within the wrapped library. "
>
>
> "since Python does not guarantee that objects will be deleted in a specific order when it exits. On the other hand, when Qt deletes an object, it always tries to delete all its children as well, which will normally ensure that objects get deleted in the right order. This is especially important when Qt takes ownership of an object, because you could end up in a situation where an attempt is made to delete the object twice (which will result in a crash)." quoted from here http://stackoverflow.com/questions/27131294/error-qobjectstarttimer-qtimer-can-only-be-used-with-threads-started-with-qt
>
>
> Since Qt ensure that objects get deleted in the right order, so is it better to let the parent argument not be None, thus causes self to be owned by Qt instead of PyQt? or just set sip.setdestroyonexit(False) ?

I think it's always a good idea to supply a parent to QObjects, except
in one of these cases:

- It's a top level window.
- You know it'll be reparented by Qt, e.g. a widget which will be
  added to a layout.

> 4) When I Wrapped the if __name__ == '__main__': part in a function main(),the issue went away ,can you explain why ? changed version https://bpaste.net/show/36c594a1c82e

That's interesting - the link above (PyQt4/PyQt5 differences)
recommends not doing that. But that's the tricky thing about such
segfaults - they don't always happen, and when you touch *something*
they maybe go away.

Florian

--
http://www.the-compiler.org | [hidden email] (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/

_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: causes self to be owned by Qt instead of PyQt ???

Phil Thompson-5
In reply to this post by iMath
On 01/04/2015 7:32 am, redstone-cold wrote:
> 1)"The parent argument, if not None, causes self to be owned by Qt
> instead of PyQt", does owned by PyQt also mean the object owned by
> Python ?

Yes.

> If it is true ,then another question below
>
>
> 2)In the doc of sip.setdestroyonexit(destroy) says, "Calling this
> function with a value of False disables the automatic destruction of
> C++ instances and C structures(owned by Python)." ,then which is
> responsible for destroying these C++ instances and C structures? the
> dtor of them ?

Nothing destroys them, the dtors never get called.

> 3)In the doc of sip.setdestroyonexit(destroy) says,"When the Python
> interpreter exits it garbage collects those objects that it can. This
> means that any corresponding C++ instances and C structures owned by
> Python are destroyed. Unfortunately this happens in an unpredictable
> order and so can cause memory faults within the wrapped library. "
>
>
> "since Python does not guarantee that objects will be deleted in a
> specific order when it exits. On the other hand, when Qt deletes an
> object, it always tries to delete all its children as well, which will
> normally ensure that objects get deleted in the right order. This is
> especially important when Qt takes ownership of an object, because you
> could end up in a situation where an attempt is made to delete the
> object twice (which will result in a crash)." quoted from here
> http://stackoverflow.com/questions/27131294/error-qobjectstarttimer-qtimer-can-only-be-used-with-threads-started-with-qt
>
>
> Since Qt ensure that objects get deleted in the right order, so is it
> better to let the parent argument not be None, thus causes self to be
> owned by Qt instead of PyQt? or just set sip.setdestroyonexit(False) ?

Generally it is a good idea to give QObject instances a parent.

> 4) When I Wrapped the if __name__ == '__main__': part in a function
> main(),the issue went away ,can you explain why ? changed version
> https://bpaste.net/show/36c594a1c82e

Just luck - the order in which Python destroys objects has changed.

Phil
_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: causes self to be owned by Qt instead of PyQt ???

iMath
In reply to this post by Florian Bruhin
> 2)In the doc of sip.setdestroyonexit(destroy) says, "Calling this function with a value of False disables the automatic destruction of C++ instances and C structures(owned by Python)." ,then which is responsible for destroying these C++ instances and C structures? the dtor of them ?

The destructors will never be called in that case - which *usually*
isn't an issue, because the application is exiting anyways.
----------------------------------------------------------------------------------------------------------------------------------
1)Then on application existing ,who destroys them ?


2)if we solve the problem via sip.setdestroyonexit(False), then I tested that the system tray icon doesn't disappear right away as application exists .




在2015年04月01 15时03分, "Florian Bruhin"<[hidden email]>写道:

Hi,

(note: I'm not 100% sure about my answers - so if I'm wrong somewhere,
someone please correct me!)

* redstone-cold <[hidden email]> [2015-04-01 14:32:19 +0800]:
> How do you know the crash happens in QObject::thread()?

(I got this off-list, but I'm answering here as well)

There are two approaches to get more info (i.e. a C++ stacktrace) when
debugging segfaults:

- Prepending the commandline with 'catchsegv'. This is very easy, but
 will print mangled C++ symbols like _ZNK7QObject6threadEv which you
 need to decode via c++filt or http://demangler.com/

- Running it inside gdb, usually with something like:

 gdb /usr/bin/python3.4 -ex run

 And then using 'bt' to get a backtrace when the segfault happens.

> sip.setdestroyonexit(False) is the default with PyQt5 ?How do you
> know this ?

I don't know where I originally picked it up, but it's listed here:

http://pyqt.sourceforge.net/Docs/PyQt5/pyqt4_differences.html#object-destruction-on-exit

> 1)"The parent argument, if not None, causes self to be owned by Qt instead of PyQt", does owned by PyQt also mean the object owned by Python ?
> If it is true ,then another question below

Yes - something is either owned by Python/PyQt, or by C++/Qt.

> 2)In the doc of sip.setdestroyonexit(destroy) says, "Calling this function with a value of False disables the automatic destruction of C++ instances and C structures(owned by Python)." ,then which is responsible for destroying these C++ instances and C structures? the dtor of them ?

The destructors will never be called in that case - which *usually*
isn't an issue, because the application is exiting anyways.

> 3)In the doc of sip.setdestroyonexit(destroy) says,"When the Python interpreter exits it garbage collects those objects that it can. This means that any corresponding C++ instances and C structures owned by Python are destroyed. Unfortunately this happens in an unpredictable order and so can cause memory faults within the wrapped library. "
>
>
> "since Python does not guarantee that objects will be deleted in a specific order when it exits. On the other hand, when Qt deletes an object, it always tries to delete all its children as well, which will normally ensure that objects get deleted in the right order. This is especially important when Qt takes ownership of an object, because you could end up in a situation where an attempt is made to delete the object twice (which will result in a crash)." quoted from here http://stackoverflow.com/questions/27131294/error-qobjectstarttimer-qtimer-can-only-be-used-with-threads-started-with-qt
>
>
> Since Qt ensure that objects get deleted in the right order, so is it better to let the parent argument not be None, thus causes self to be owned by Qt instead of PyQt? or just set sip.setdestroyonexit(False) ?

I think it's always a good idea to supply a parent to QObjects, except
in one of these cases:

- It's a top level window.
- You know it'll be reparented by Qt, e.g. a widget which will be
 added to a layout.

> 4) When I Wrapped the if __name__ == '__main__': part in a function main(),the issue went away ,can you explain why ? changed version https://bpaste.net/show/36c594a1c82e

That's interesting - the link above (PyQt4/PyQt5 differences)
recommends not doing that. But that's the tricky thing about such
segfaults - they don't always happen, and when you touch *something*
they maybe go away.

Florian

--
http://www.the-compiler.org | [hidden email] (Mail/XMPP)
  GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
        I love long mails! | http://email.is-not-s.ms/



_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: causes self to be owned by Qt instead of PyQt ???

iMath
In reply to this post by Phil Thompson-5

>> 2)In the doc of sip.setdestroyonexit(destroy) says, "Calling this
>> function with a value of False disables the automatic destruction of
>> C++ instances and C structures(owned by Python)." ,then which is
>> responsible for destroying these C++ instances and C structures? the
>> dtor of them ?
> Nothing destroys them, the dtors never get called.
> 1)Then on application existing ,who destroys them ?

As I said - nothing, the dtors never get called.


1)Does this mean these C++ instances and C structures still exist in memory even when application existed ?
----------------------------------------------------------------------------------------------------------------------------------



> 3)Can you explain why Python has stopped working in this issue ?
> http://www.riverbankcomputing.com/pipermail/pyqt/2015-March/035730.html

No.

> Any way to solve the problem ?
> if we solve the problem via sip.setdestroyonexit(False),  then I
> tested on Windows that the system tray icon doesn't disappear right away as
> application exists .

2)Is this a bug with PyQt ?
----------------------------------------------------------------------------------------------------------------------------------

> 4)bug report : QFileSystemModel.parent() doesn't exist ,but it should
> have one according to the Qt doc.

It does exist.

3)Have you tested it ? I tested in PyQt4 that QFileSystemModel.parent() doesn't work .
----------------------------------------------------------------------------------------------------------------------------------



在2015年04月01 21时48分, "Phil Thompson"<[hidden email]>写道:

On 01/04/2015 2:19 pm, redstone-cold wrote:
>> 2)In the doc of sip.setdestroyonexit(destroy) says, "Calling this
>> function with a value of False disables the automatic destruction of
>> C++ instances and C structures(owned by Python)." ,then which is
>> responsible for destroying these C++ instances and C structures? the
>> dtor of them ?
>
> Nothing destroys them, the dtors never get called.
> ----------------------------------------------------------------------------------------------------------------------------------
> 1)Then on application existing ,who destroys them ?

As I said - nothing, the dtors never get called.

>
>
> 2)Since sip.setdestroyonexit(True) may cause memory faults, why not
> make sip.setdestroyonexit(False) be the default.

Backwards compatibility. False is the default for PyQt5.

>
>
> 3)Can you explain why Python has stopped working in this issue ?
> http://www.riverbankcomputing.com/pipermail/pyqt/2015-March/035730.html

No.

> Any way to solve the problem ?
> if we solve the problem via sip.setdestroyonexit(False),  then I
> tested that the system tray icon doesn't disappear right away as
> application exists .
>
>
>
>
> 4)bug report : QFileSystemModel.parent() doesn't exist ,but it should
> have one according to the Qt doc.

It does exist.

> QAbstractTableModel also has the same bug.

Phil



_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: causes self to be owned by Qt instead of PyQt ???

Phil Thompson-5
On 02/04/2015 6:05 am, redstone-cold wrote:

>>> 2)In the doc of sip.setdestroyonexit(destroy) says, "Calling this
>>> function with a value of False disables the automatic destruction of
>>> C++ instances and C structures(owned by Python)." ,then which is
>>> responsible for destroying these C++ instances and C structures? the
>>> dtor of them ?
>>
>> Nothing destroys them, the dtors never get called.
>>
>> 1)Then on application existing ,who destroys them ?
>
>
> As I said - nothing, the dtors never get called.
>
>
>
>
> 1)Does this mean these C++ instances and C structures still exist in
> memory even when application existed ?
> ----------------------------------------------------------------------------------------------------------------------------------

No - you need to read a basic introduction to operating systems book.

>> 3)Can you explain why Python has stopped working in this issue ?
>> http://www.riverbankcomputing.com/pipermail/pyqt/2015-March/035730.html
>
>
> No.
>
>
>> Any way to solve the problem ?
>> if we solve the problem via sip.setdestroyonexit(False),  then I
>> tested on Windows that the system tray icon doesn't disappear right
>> away as
>> application exists .
>>
>
>
> 2)Is this a bug with PyQt ?
> ----------------------------------------------------------------------------------------------------------------------------------

No.

>> 4)bug report : QFileSystemModel.parent() doesn't exist ,but it should
>> have one according to the Qt doc.
>
>
> It does exist.
>
>
> 3)Have you tested it ? I tested in PyQt4 that
> QFileSystemModel.parent() doesn't work .
> ----------------------------------------------------------------------------------------------------------------------------------

"Doesn't work" is very different to "doesn't exist". If you think there
is a bug then post a simple, complete example demonstrating the problem.

Phil
_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: causes self to be owned by Qt instead of PyQt ???

iMath


Ok, this is the example 
https://bpaste.net/show/a5b2b50e5052

BTW,if you comment print(model.parent()),then console show
QObject::startTimer: QTimer can only be used with threads started with QThread

what's wrong in the code ?

在2015年04月02 18时04分, "Phil Thompson"<[hidden email]>写道:

On 02/04/2015 6:05 am, redstone-cold wrote:

>>> 2)In the doc of sip.setdestroyonexit(destroy) says, "Calling this
>>> function with a value of False disables the automatic destruction of
>>> C++ instances and C structures(owned by Python)." ,then which is
>>> responsible for destroying these C++ instances and C structures? the
>>> dtor of them ?
>>
>> Nothing destroys them, the dtors never get called.
>>
>> 1)Then on application existing ,who destroys them ?
>
>
> As I said - nothing, the dtors never get called.
>
>
>
>
> 1)Does this mean these C++ instances and C structures still exist in
> memory even when application existed ?
> ----------------------------------------------------------------------------------------------------------------------------------

No - you need to read a basic introduction to operating systems book.

>> 3)Can you explain why Python has stopped working in this issue ?
>> http://www.riverbankcomputing.com/pipermail/pyqt/2015-March/035730.html
>
>
> No.
>
>
>> Any way to solve the problem ?
>> if we solve the problem via sip.setdestroyonexit(False),  then I
>> tested on Windows that the system tray icon doesn't disappear right
>> away as
>> application exists .
>>
>
>
> 2)Is this a bug with PyQt ?
> ----------------------------------------------------------------------------------------------------------------------------------

No.

>> 4)bug report : QFileSystemModel.parent() doesn't exist ,but it should
>> have one according to the Qt doc.
>
>
> It does exist.
>
>
> 3)Have you tested it ? I tested in PyQt4 that
> QFileSystemModel.parent() doesn't work .
> ----------------------------------------------------------------------------------------------------------------------------------

"Doesn't work" is very different to "doesn't exist". If you think there
is a bug then post a simple, complete example demonstrating the problem.

Phil



_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: causes self to be owned by Qt instead of PyQt ???

Andreas Pakulat
Hi,

On Thu, Apr 2, 2015 at 3:18 PM, redstone-cold <[hidden email]> wrote:


Ok, this is the example 

BTW,if you comment print(model.parent()),then console show
QObject::startTimer: QTimer can only be used with threads started with QThread

what's wrong in the code ?

QAbstractItemModel.parent() require an argument, so calling it without an argument is a bug.

And the message is printed regardless of wether the print is there or not, thats likely an internal issue in Qt.

Andreas

_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: causes self to be owned by Qt instead of PyQt ???

Baz Walter
On 02/04/15 17:18, Andreas Pakulat wrote:

> On Thu, Apr 2, 2015 at 3:18 PM, redstone-cold <[hidden email]> wrote:
>>
>> Ok, this is the example
>> https://bpaste.net/show/a5b2b50e5052
>>
>> BTW,if you comment print(model.parent()),then console show
>> QObject::startTimer: QTimer can only be used with threads started with
>> QThread
>>
>> what's wrong in the code ?
>
> QAbstractItemModel.parent() require an argument, so calling it without an
> argument is a bug.
>
> And the message is printed regardless of wether the print is there or not,
> thats likely an internal issue in Qt.

QAbstractItemModel.parent(QModelIndex) overloads QObject.parent(), so it
is a bug in PyQt4/5 that it doesn't support the latter.

That doesn't explain what is wrong with the code though. The problem
there is the same as the other example the OP posted, and has the same
kinds of solutions (e.g. give the model a parent, or use
sip.setdestroyonexit(False)).

--
Regards
Baz Walter
_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: causes self to be owned by Qt instead of PyQt ???

Baz Walter
On 02/04/15 17:38, Baz Walter wrote:
> QAbstractItemModel.parent(QModelIndex) overloads QObject.parent(), so it
> is a bug in PyQt4/5 that it doesn't support the latter.

To be more precise: it's QFileSystemModel that has the missing overload
in PyQt4/5, not the QAbstractItemModel base-class.

_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: causes self to be owned by Qt instead of PyQt ???

Phil Thompson-5
In reply to this post by Baz Walter
On 02/04/2015 5:38 pm, Baz Walter wrote:

> On 02/04/15 17:18, Andreas Pakulat wrote:
>> On Thu, Apr 2, 2015 at 3:18 PM, redstone-cold <[hidden email]>
>> wrote:
>>>
>>> Ok, this is the example
>>> https://bpaste.net/show/a5b2b50e5052
>>>
>>> BTW,if you comment print(model.parent()),then console show
>>> QObject::startTimer: QTimer can only be used with threads started
>>> with
>>> QThread
>>>
>>> what's wrong in the code ?
>>
>> QAbstractItemModel.parent() require an argument, so calling it without
>> an
>> argument is a bug.
>>
>> And the message is printed regardless of wether the print is there or
>> not,
>> thats likely an internal issue in Qt.
>
> QAbstractItemModel.parent(QModelIndex) overloads QObject.parent(), so
> it is a bug in PyQt4/5 that it doesn't support the latter.

Eh? The QAbstractItemModel parent() hides the QObject parent().

Phil
_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: causes self to be owned by Qt instead of PyQt ???

Baz Walter
On 02/04/15 18:33, Phil Thompson wrote:
> On 02/04/2015 5:38 pm, Baz Walter wrote:
>> On 02/04/15 17:18, Andreas Pakulat wrote:
>>
>> QAbstractItemModel.parent(QModelIndex) overloads QObject.parent(), so
>> it is a bug in PyQt4/5 that it doesn't support the latter.
>
> Eh? The QAbstractItemModel parent() hides the QObject parent().

No, it shouldn't do. A QAbstractItemModel is a QObject. It takes another
QObject as its parent, not a QModelIndex:

 >>> from PyQt4 import QtCore, QtGui
 >>> app = QtGui.QApplication([])
 >>> model = QtGui.QStandardItemModel(app)
 >>> model.parent()
<PyQt4.QtGui.QApplication object at 0x7f397aae0c18>
 >>> model.parent(QtCore.QModelIndex())
<PyQt4.QtCore.QModelIndex object at 0x7f3975078358>

QAbstractItemModel::parent(QModelIndex) is virtual, but
QObject::parent() isn't, so it cannot not be overridden.

_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: causes self to be owned by Qt instead of PyQt ???

Baz Walter
On 02/04/15 19:37, Baz Walter wrote:

> On 02/04/15 18:33, Phil Thompson wrote:
>> On 02/04/2015 5:38 pm, Baz Walter wrote:
>>> On 02/04/15 17:18, Andreas Pakulat wrote:
>>>
>>> QAbstractItemModel.parent(QModelIndex) overloads QObject.parent(), so
>>> it is a bug in PyQt4/5 that it doesn't support the latter.
>>
>> Eh? The QAbstractItemModel parent() hides the QObject parent().
>
> No, it shouldn't do. A QAbstractItemModel is a QObject. It takes another
> QObject as its parent, not a QModelIndex:
>
>  >>> from PyQt4 import QtCore, QtGui
>  >>> app = QtGui.QApplication([])
>  >>> model = QtGui.QStandardItemModel(app)
>  >>> model.parent()
> <PyQt4.QtGui.QApplication object at 0x7f397aae0c18>
>  >>> model.parent(QtCore.QModelIndex())
> <PyQt4.QtCore.QModelIndex object at 0x7f3975078358>
>
> QAbstractItemModel::parent(QModelIndex) is virtual, but
> QObject::parent() isn't, so it cannot not be overridden.
>

Of course, I meant "it cannot be overridden".

PS: I tested most of the other built-in model classes, and it just seems
to be QFileSystemModel that is lacking QObject::parent().

--
Regards
Baz Walter
_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: causes self to be owned by Qt instead of PyQt ???

Phil Thompson-5
In reply to this post by Baz Walter
On 02/04/2015 7:37 pm, Baz Walter wrote:

> On 02/04/15 18:33, Phil Thompson wrote:
>> On 02/04/2015 5:38 pm, Baz Walter wrote:
>>> On 02/04/15 17:18, Andreas Pakulat wrote:
>>>
>>> QAbstractItemModel.parent(QModelIndex) overloads QObject.parent(), so
>>> it is a bug in PyQt4/5 that it doesn't support the latter.
>>
>> Eh? The QAbstractItemModel parent() hides the QObject parent().
>
> No, it shouldn't do. A QAbstractItemModel is a QObject. It takes
> another QObject as its parent, not a QModelIndex:
>
>>>> from PyQt4 import QtCore, QtGui
>>>> app = QtGui.QApplication([])
>>>> model = QtGui.QStandardItemModel(app)
>>>> model.parent()
> <PyQt4.QtGui.QApplication object at 0x7f397aae0c18>
>>>> model.parent(QtCore.QModelIndex())
> <PyQt4.QtCore.QModelIndex object at 0x7f3975078358>
>
> QAbstractItemModel::parent(QModelIndex) is virtual, but
> QObject::parent() isn't, so it cannot not be overridden.
So the attached C++ code should compile?

Phil
_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

test.cpp (316 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: causes self to be owned by Qt instead of PyQt ???

Andreas Pakulat
Hi Phil,

On Thu, Apr 2, 2015 at 11:11 PM, Phil Thompson <[hidden email]> wrote:
On 02/04/2015 7:37 pm, Baz Walter wrote:
On 02/04/15 18:33, Phil Thompson wrote:
On 02/04/2015 5:38 pm, Baz Walter wrote:
On 02/04/15 17:18, Andreas Pakulat wrote:

QAbstractItemModel.parent(QModelIndex) overloads QObject.parent(), so
it is a bug in PyQt4/5 that it doesn't support the latter.

Eh? The QAbstractItemModel parent() hides the QObject parent().

No, it shouldn't do. A QAbstractItemModel is a QObject. It takes
another QObject as its parent, not a QModelIndex:

from PyQt4 import QtCore, QtGui
app = QtGui.QApplication([])
model = QtGui.QStandardItemModel(app)
model.parent()
<PyQt4.QtGui.QApplication object at 0x7f397aae0c18>
model.parent(QtCore.QModelIndex())
<PyQt4.QtCore.QModelIndex object at 0x7f3975078358>

QAbstractItemModel::parent(QModelIndex) is virtual, but
QObject::parent() isn't, so it cannot not be overridden.

So the attached C++ code should compile?

Not without a fix for qfilesystemmodel.h. qabstractitemmodel.h as well as qstandarditemmodel.h (and probably other qaim subclasses in qt) explicitly 'reuse' QObject::parent using something like:

#ifdef Q_NO_USING_KEYWORD
    inline QObject *parent() const { return QObject::parent(); }
#else
    using QObject::parent;
#endif

For qfilesystemmodel.h this is missing and hence one cannot call QObject::parent() with a pointer or instance of it.

Andreas

_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: causes self to be owned by Qt instead of PyQt ???

Baz Walter
On 02/04/15 23:01, Andreas Pakulat wrote:

> Hi Phil,
>
> On Thu, Apr 2, 2015 at 11:11 PM, Phil Thompson <[hidden email]>
> wrote:
>>
>> So the attached C++ code should compile?
>
> Not without a fix for qfilesystemmodel.h. qabstractitemmodel.h as well as
> qstandarditemmodel.h (and probably other qaim subclasses in qt) explicitly
> 'reuse' QObject::parent using something like:
>
> #ifdef Q_NO_USING_KEYWORD
>      inline QObject *parent() const { return QObject::parent(); }
> #else
>      using QObject::parent;
> #endif
>
> For qfilesystemmodel.h this is missing and hence one cannot call
> QObject::parent() with a pointer or instance of it.

Huh. So is it a Qt bug, then? Seems a little strange that it has gone
unnoticed for so long (since at least 4.7). But maybe there's a specific
reason why QFileSystemModel is be treated differently to all the other
model classes.

Looks like Q_NO_USING_KEYWORD has been completely removed in Qt-5.5, but
obviously that didn't touch qfilesystemmodel.h, so parent() is still
missing there.

--
Regards
Baz Walter
_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: causes self to be owned by Qt instead of PyQt ???

Phil Thompson-5
On 02/04/2015 11:54 pm, Baz Walter wrote:

> On 02/04/15 23:01, Andreas Pakulat wrote:
>> Hi Phil,
>>
>> On Thu, Apr 2, 2015 at 11:11 PM, Phil Thompson
>> <[hidden email]>
>> wrote:
>>>
>>> So the attached C++ code should compile?
>>
>> Not without a fix for qfilesystemmodel.h. qabstractitemmodel.h as well
>> as
>> qstandarditemmodel.h (and probably other qaim subclasses in qt)
>> explicitly
>> 'reuse' QObject::parent using something like:
>>
>> #ifdef Q_NO_USING_KEYWORD
>>      inline QObject *parent() const { return QObject::parent(); }
>> #else
>>      using QObject::parent;
>> #endif
>>
>> For qfilesystemmodel.h this is missing and hence one cannot call
>> QObject::parent() with a pointer or instance of it.
>
> Huh. So is it a Qt bug, then? Seems a little strange that it has gone
> unnoticed for so long (since at least 4.7). But maybe there's a
> specific reason why QFileSystemModel is be treated differently to all
> the other model classes.
>
> Looks like Q_NO_USING_KEYWORD has been completely removed in Qt-5.5,
> but obviously that didn't touch qfilesystemmodel.h, so parent() is
> still missing there.

...so it's not a PyQt bug :)

Phil
_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: causes self to be owned by Qt instead of PyQt ???

iMath
reported here  https://bugreports.qt.io/browse/QTBUG-45393



在2015年04月03 16时19分, "Phil Thompson"<[hidden email]>写道:

On 02/04/2015 11:54 pm, Baz Walter wrote:

> On 02/04/15 23:01, Andreas Pakulat wrote:
>> Hi Phil,
>>
>> On Thu, Apr 2, 2015 at 11:11 PM, Phil Thompson
>> <[hidden email]>
>> wrote:
>>>
>>> So the attached C++ code should compile?
>>
>> Not without a fix for qfilesystemmodel.h. qabstractitemmodel.h as well
>> as
>> qstandarditemmodel.h (and probably other qaim subclasses in qt)
>> explicitly
>> 'reuse' QObject::parent using something like:
>>
>> #ifdef Q_NO_USING_KEYWORD
>>      inline QObject *parent() const { return QObject::parent(); }
>> #else
>>      using QObject::parent;
>> #endif
>>
>> For qfilesystemmodel.h this is missing and hence one cannot call
>> QObject::parent() with a pointer or instance of it.
>
> Huh. So is it a Qt bug, then? Seems a little strange that it has gone
> unnoticed for so long (since at least 4.7). But maybe there's a
> specific reason why QFileSystemModel is be treated differently to all
> the other model classes.
>
> Looks like Q_NO_USING_KEYWORD has been completely removed in Qt-5.5,
> but obviously that didn't touch qfilesystemmodel.h, so parent() is
> still missing there.

...so it's not a PyQt bug :)

Phil
_______________________________________________
PyQt mailing list    [hidden email]



_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt