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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > On Monday 17 July 2006 10:09 pm, Arve Knudsen wrote: > > > On 7/17/06, Andreas Pakulat <[EMAIL PROTECTED]> 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 [email protected] > > http://mats.imk.fraunhofer.de/mailman/listinfo/pykde > > _______________________________________________ > PyKDE mailing list [email protected] > http://mats.imk.fraunhofer.de/mailman/listinfo/pykde _______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
_______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
