I thought about this some more, and then returned to an earlier
message of James'. I think I spotted a flaw in James' logic. Here is
the excerpt:
I looked at this a bit, but it is a little difficult. First of all, you
want these two things to occur:
- The C level GtkObject should not die while the python representation
is arround (this is what currently occus).
- The python representation should not get garbage collected while the C
GtkObject is arround.
Now, James proceeds to explain how this inherently implies a circular
reference. However, I think the flaw in the logic is in the first
clause. In my opinion, the Gtk object should very well be allowed to
die while the Python representation is around -- it is only the second
clause that is really necessary for things to function. Let me expand
on this:
1) Every Gtk object visible to Python corresponds to exactly one
Python object.
2) The Gtk object is registered as a "reference" to the Python object,
increasing its refcount. When the Gtk object dies, the Python
object's refcount is decreased, possibly destroying it.
3) As a corollary of #2, a Python object may continue to live after
the corresponding Gtk object dies. Also as a corollary, the
reverse is not true -- the Gtk object cannot live if its Python
object is dead.
4) When the Gtk object dies and the Python object survives (because of
being referenced elsewhere in Python), the Python object knows its
Gtk object is dead and will raise errors if someone tries to use
the contained dead Gtk object in any fashion whatsoever.
5) The Gtk object stores the corresponding Python object in an
internal "data" field. No global dictionaries are necessary.
I see no circularities here because the internal Gtk objects (which
indeed contain a pointer back to the Python object) are not visible to
Python's GC. Some of the possible cases follow...
def somefunc ():
window = GtkWindow ()
...
return
Now, somefunc() creates a Python object and a Gtk object. Because
there are no other references to the Python object, it will live as
long as its corresponding Gtk object lives. If a callback is called,
the same Python object will be passed (with all the user's attributes
intact) because the Gtk object "knows" what Python object it belongs
to.
The second case is something like this:
def somefunc ():
window = GtkWindow ()
...
return window
window = somefunc ()
...
window.destroy ()
Now, window can be referenced in many places in Python. The
.destroy() callback will destroy its internal Gtk object, but this
will merely decrement its refcount. After the Gtk object dies, the
Python object knows it, so that something like this will raise an
exception:
window.show () # oh no you won't, the Gtk object is dead
Sorry for the length. James, if you think this won't work, I'd like
to see what I'm missing.
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
