[prev in list] [next in list] [prev in thread] [next in thread]
List: pykde
Subject: Re: [PyKDE] PyQt4 problems with underlying C/C++ objects [weird]
From: "Krystian Samp" <samp.krystian () gmail ! com>
Date: 2006-11-21 18:46:13
Message-ID: cfa896710611211046t63565929o992e0198a0422ce4 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
you are right guys, it just can not be solved in a better way. I think it
should be explained somewhere since this is not a trivial issue, is it?
cheers,
Krystian
2006/11/21, Giovanni Bajo <rasky@develer.com>:
>
> Krystian Samp wrote:
>
> >> It seems that when you create an item the python object holds a
> >> reference to it. However, if you assign that item to a hierarchy of
> >> items (for instance using setParentItem()) the python object loses
> >> (or you can say hands over) the reference. This reference still
> >> exists in the C/C++ level in the hierarchy but only there. So If you
> >> stop referencing to the parent of the item then the item itself will
> >> be destroyed as well. This is weird since you still have a python
> >> object representing the item but as I said it handed over the
> >> reference to the C/C++ layer. This is my observation and I think
> >> it's not a good behavior of PyQt since you actually have to think
> >> about C/C++ and the principle I've described.
>
> Well, you HAVE to know what C++ does anyway. If the C++-side thinks that
> the
> parent owns the ownership of the child, there is nothing PyQt can do to
> prevehent it. If the C++ side then destroys that item (because eg. the
> parent kills it), there's nothing PyQt can do to prevent the object from
> being deallocate. I'll give you a short example of what I mean:
>
> class Foo(QWidget):
> def __init__(self, parent):
> QWidget.__init__(self, parent)
> self.bar = QWidget(self)
>
> f = Foo(None)
> b = f.bar
> del f
> # what about b?
>
> In this case, Python still holds a reference to "b", but the underlying
> QWidget in C++ has been destroyed because it was child of "f" and "f" was
> destroyed. There's nothing PyQt can do to prehevent this: on the contrary,
> it *exposes* this behaviour, which is the way QObject's ownership system
> works.
>
> In other words, you can't ignore this problem, you must know and
> understand
> QObject lifetime. You can't assume that, since you have a Python
> reference,
> the underlying object will stay alive forever.
> --
> Giovanni Bajo
>
>
[Attachment #5 (text/html)]
you are right guys, it just can not be solved in a better way. I think it should be \
explained somewhere since this is not a trivial issue, is \
it?<br><br>cheers,<br>Krystian<br><br><div><span class="gmail_quote">2006/11/21, \
Giovanni Bajo < <a \
href="mailto:rasky@develer.com">rasky@develer.com</a>>:</span><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;">Krystian Samp wrote:<br> <br>>> It seems that \
when you create an item the python object holds a<br>>> reference to it. \
However, if you assign that item to a hierarchy of<br>>> items (for instance \
using setParentItem()) the python object loses <br>>> (or you can say hands \
over) the reference. This reference still<br>>> exists in the C/C++ level in \
the hierarchy but only there. So If you<br>>> stop referencing to the parent of \
the item then the item itself will <br>>> be destroyed as well. This is weird \
since you still have a python<br>>> object representing the item but as I said \
it handed over the<br>>> reference to the C/C++ layer. This is my observation \
and I think <br>>> it's not a good behavior of PyQt since you actually have to \
think<br>>> about C/C++ and the principle I've described.<br><br>Well, you HAVE \
to know what C++ does anyway. If the C++-side thinks that the<br> parent owns the \
ownership of the child, there is nothing PyQt can do to<br>prevehent it. If the C++ \
side then destroys that item (because eg. the<br>parent kills it), there's nothing \
PyQt can do to prevent the object from <br>being deallocate. I'll give you a short \
example of what I mean:<br><br>class Foo(QWidget):<br> def \
__init__(self, parent):<br> \
QWidget.__init__(self, parent)<br> \
self.bar = QWidget(self)<br><br>f = Foo(None) <br>b = f.bar<br>del f<br># what about \
b?<br><br>In this case, Python still holds a reference to "b", but the \
underlying<br>QWidget in C++ has been destroyed because it was child of "f" \
and "f" was <br>destroyed. There's nothing PyQt can do to prehevent this: \
on the contrary,<br>it *exposes* this behaviour, which is the way QObject's ownership \
system<br>works.<br><br>In other words, you can't ignore this problem, you must know \
and understand <br>QObject lifetime. You can't assume that, since you have a Python \
reference,<br>the underlying object will stay alive forever.<br>--<br>Giovanni \
Bajo<br><br></blockquote></div><br>
_______________________________________________
PyKDE mailing list PyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic