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

[Allen Bierbaum]

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.

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.

If there is any way to make this work I think it would greatly improve PyQT.

Thanks,
Allen

On 8/17/06, Phil Thompson <phil at riverbankcomputing.co.uk> wrote:
> Having looked at this yet again it's clear that it's not possible to implement
> this without leaking Python references. I don't know why I thought it was
> possible at one stage.
>
> The obvious problems are the lack of virtual dtor (so there is no place to
> reliably decrement the reference count) and the assignment operator (so the
> reference count won't get incremented when Qt assigns instances internally).
>
> For the same reasons it's not possible to do anything with
> QPersistentModelIndex.
>
> Phil
>
> On Wednesday 26 July 2006 9:05 am, Arve Knudsen wrote:
> > Phil, did you reach any conclusion on this? I think model/view
> > programming is so integral to Qt 4 programming it should warrant some
> > extra attention in a Python layer.
> >
> > Arve
> >
> > On 7/18/06, Phil Thompson <phil at riverbankcomputing.co.uk> wrote:
> > > On Monday 17 July 2006 10:09 pm, Arve Knudsen wrote:
> > > > On 7/17/06, Andreas Pakulat <apaku at gmx.de> wrote:
> > > > > On 17.07.06 22:00:41, Arve Knudsen wrote:
> > > > > > Ok, I found the original thread. There is no explanation as to why
> > > > > > no extra reference is kept however.
> > > > >
> > > > > I don't know too much about python refcounting, but I think one
> > > > > problem could be what to do if the model index disappears. Also
> > > > > decrease the reference count? This could lead to a problem if
> > > > > "something" else still needs the object... Phil needs to answer this.
> > > >
> > > > When the model index is destroyed, it should decrease the reference
> > > > count seems like the obvious answer. If the object is referred to
> > > > elsewhere its reference count should reflect this.
> > >
> > > And you also have to implement the hooks for the cyclic garbage
> > > collector.
> > >
> > > > > > There might be a good reason for this
> > > > > > behaviour, but it does represent a rather nasty pitfall.
> > > > >
> > > > > Well, that's probably a reason why it was introduced so late, you had
> > > > > to use internalId before.
> > > >
> > > > My impression from reading the thread is that it was non-trivial to
> > > > implement, but added out of a real need, expressed by users.
> > >
> > > It was trivial to implement, once it was pointed out to me that the
> > > original (automated) wrapping was useless given the way it is supposed to
> > > be used.
> > >
> > > There are plenty of other places where you have to keep an external
> > > reference to stop an object being garbage collected causing a crash. I
> > > just need to decide if this is worth making a special case.
> > >
> > > Phil
> > >
> > > _______________________________________________
> > > PyKDE mailing list    PyKDE at mats.imk.fraunhofer.de
> > > http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
> >
> > _______________________________________________
> > PyKDE mailing list    PyKDE at mats.imk.fraunhofer.de
> > http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
>
> _______________________________________________
> PyKDE mailing list    PyKDE at mats.imk.fraunhofer.de
> http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
>