Internal Pointers again... Was: [PyKDE] Model indexes and internal pointers

David Boddie david at boddie.org.uk
Tue Sep 19 22:48:48 BST 2006


On Tuesday 19 September 2006 08:36:31 +0100 (BST), Phil Thompson wrote:

Allen Bierbaum wrote:

> > Phil et al:
> >
> > How much of a lost cause is this?  I ask because I just got bit by
> > this bug and ate up nearly a day trying to track down a very nasty seg
> > fault.   As Arve said in the original thread, Model-View programming
> > is a core of QT and this issue makes it very difficult to successfully
> > program this type of system.  I think it is especially relevant to
> > PyQT because it is very common to have temporary python wrappers
> > hanging around when interfacing with C++ code.

I still think that there will be problems with temporary objects, whether
in Python or in C++. If you are creating temporary Python wrappers that
can presumably have different identities each time they wrap the same
underlying object, you still need a way to identify them. To guarantee that
the Python wrappers stay around, you may need to ensure that Python owns
the objects, and this may interfere with the way the underlying library
works.

> > In my case I have wrappers around a scene graph (a tree structure for
> > computer graphics).  Anytime I call through to C++ and ask the tree
> > nodes for children or parents, I get a python wrapper back.  This
> > wrapper is referencing a ref-counted class on the C++ side, but it is
> > unique as far as python is concerned.  So when I put this into
> > internalPointer to retrieve later it immediately goes out of scope in
> > python and is invalid when I try to reference it later.

This sounds quite like the problems that occur when trying to create a model
that exposes QDomDocument, both in C++ and in Python. Unfortunately, the
only reasonable approach that didn't take advantage of internal mechanisms
in QDomNode was to replicate the structure of the documents using custom
item objects.

> > If there is any way to make this work I think it would greatly improve
> > PyQT.
>
> It isn't technically possible - unless somebody has a bright idea.

I think it might be useful to have a convenience class to help people write
models in Python, or at least something to start from.

David




More information about the PyQt mailing list