Phil: Might it be an idea to make QModelIndex update the reference
count for its "internalPointer"? This is only a suggestion on my part,
as I'm in not an expert on Python/C++ interfacing. I just resolved
some mysterious segfaults in an application of mine to a temporary
Python object being stored in a QModelIndex, and some robustness
towards this sort of thing in PyQt would be great.
Arve
PyKDE mailing list PyKDE (AT) mats (DOT) imk.fraunhofer.de

7/17/06, Andreas Pakulat <apaku (AT) gmx (DOT) dewrote:
17.07.06 22:00:41, Arve Knudsen wrote:
, 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.

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.

Arve

PyKDE mailing list PyKDE (AT) mats (DOT) imk.fraunhofer.de

Monday 17 July 2006 10:09 pm, Arve Knudsen wrote:
7/17/06, Andreas Pakulat <apaku (AT) gmx (DOT) dewrote:
17.07.06 22:00:41, Arve Knudsen wrote:
, 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 (DOT) imk.fraunhofer.de

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

7/18/06, Phil Thompson <phil (AT) riverbankcomputing (DOT) co.ukwrote:
Monday 17 July 2006 10:09 pm, Arve Knudsen wrote:
7/17/06, Andreas Pakulat <apaku (AT) gmx (DOT) dewrote:
17.07.06 22:00:41, Arve Knudsen wrote:
, 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 (DOT) imk.fraunhofer.de

PyKDE mailing list PyKDE (AT) mats (DOT) imk.fraunhofer.de

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.

I'm inclined to agree with you, particularly as it seems reasonably easy to
implement and won't break existing code.

I'm rather busy at the moment, but I'll shout when I make the change.

Phil

PyKDE mailing list PyKDE (AT) mats (DOT) imk.fraunhofer.de

Appreciated.

Arve

7/26/06, Phil Thompson <phil (AT) riverbankcomputing (DOT) co.ukwrote:
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.

I'm inclined to agree with you, particularly as it seems reasonably easy to
implement and won't break existing code.

I'm rather busy at the moment, but I'll shout when I make the change.

Phil

PyKDE mailing list PyKDE (AT) mats (DOT) imk.fraunhofer.de

PyKDE mailing list PyKDE (AT) mats (DOT) imk.fraunhofer.de

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

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

7/18/06, Phil Thompson <phil (AT) riverbankcomputing (DOT) co.ukwrote:
Monday 17 July 2006 10:09 pm, Arve Knudsen wrote:
7/17/06, Andreas Pakulat <apaku (AT) gmx (DOT) dewrote:
17.07.06 22:00:41, Arve Knudsen wrote:
, 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 (DOT) imk.fraunhofer.de

PyKDE mailing list PyKDE (AT) mats (DOT) imk.fraunhofer.de

PyKDE mailing list PyKDE (AT) mats (DOT) imk.fraunhofer.de

8/17/06, Phil Thompson <phil (AT) riverbankcomputing (DOT) co.ukwrote:
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.

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

Arve

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

7/18/06, Phil Thompson <phil (AT) riverbankcomputing (DOT) co.ukwrote:
Monday 17 July 2006 10:09 pm, Arve Knudsen wrote:
7/17/06, Andreas Pakulat <apaku (AT) gmx (DOT) dewrote:
17.07.06 22:00:41, Arve Knudsen wrote:
, 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 (DOT) imk.fraunhofer.de

PyKDE mailing list PyKDE (AT) mats (DOT) imk.fraunhofer.de

PyKDE mailing list PyKDE (AT) mats (DOT) imk.fraunhofer.de

PyKDE mailing list PyKDE (AT) mats (DOT) imk.fraunhofer.de

Am Samstag, 19. August 2006 01:39 schrieb Arve Knudsen:
8/17/06, Phil Thompson <phil (AT) riverbankcomputing (DOT) co.ukwrote:
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.

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

Arve

Nope, it's your call to find the right tree to bark up

Pete

PyKDE mailing list PyKDE (AT) mats (DOT) imk.fraunhofer.de

8/19/06, Hans-Peter Jansen <hpj (AT) urpla (DOT) netwrote:
Nope, it's your call to find the right tree to bark up

Well, I'm not going to pursue this issue any further. I have enough on
my agenda for the time being.

Arve

PyKDE mailing list PyKDE (AT) mats (DOT) imk.fraunhofer.de