[Python-Dev] Weak references: dereference notification

["Martin v. Löwis"]

Gustavo J. A. M. Carneiro wrote:
>   OK, but what if it is a subclass of a builtin type, with instance
> variables?  What if the PyObject is GC'ed but the ObjC object remains
> alive, and later you get a new reference to it?  Do you create a new
> PyObject wrapper for it?  What happened to the instance variables?

Normally, wrappers don't have state. But if you do have state, this
is how it could work:

1. Make two Python objects, PyState and PyWrapper (actually,
    PyState doesn't need to be a Python object)
    PyState holds the instance variables, and PyWrapper just
    holds a pointer to a GObject.
2. When a Python reference to a GObject is created for the
    first time, create both a PyState and a PyWrapper. Have
    the GObject point to the PyState, and the PyWrapper to
    the GObject. Have the PyState weakly reference the
    PyWrapper.
3. When the refcount to the PyWrapper drops to zero, discard it.
4. When somebody asks for the data in the PyWrapper,
    go to the GObject, then to the PyState, and return the
    data from there.
5. When somebody wants a reference to a GObject which already
    has a PyState, check the weak reference to find out
    whether there is a PyWrapper already. If yes, return it;
    if not, create a new one (and weakly reference it).
6. When the GObject is discarded, drop the PyState as well.

This has the following properties:
1. There are no cyclic references for wrapping GObjects.
2. Weakly-referencing wrappers is supported; if there
    are no strong Python references to the wrapper,
    the wrapper goes away, and, potentially, the GObject
    as well.
3. The PyState object lives as long as the GObject.
4. Using "is" for GObjects/PyWrappers "works": there is
    at most one PyWrapper per GObject at any time.
5. id() of a GObject may change over time, if the wrapper
    becomes unreferenced and then recreated.

Regards,
Martin