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.

Oh .. Too bad, guess we'll have to live with this :\

Arve


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    PyKDE@mats.imk.fraunhofer.de
> > http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
>
> _______________________________________________
> PyKDE mailing list    PyKDE@mats.imk.fraunhofer.de
> http://mats.imk.fraunhofer.de/mailman/listinfo/pykde

_______________________________________________
PyKDE mailing list    PyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


_______________________________________________
PyKDE mailing list    PyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde

Reply via email to