Does pygtk garbage-collect runtime-created functions connected to signals?
Question: I'm using PyGtk.

Will a **runtime-generated** function connected to the signal "drag_data_get"
of a widget be **garbage-collected** when the widget is **destroyed** ?

Same question about the Gtk.TargetList that are created and associated with
drag source/dest target?

I did found [Python and GTK+: How to create garbage collector friendly
objects?](http://stackoverflow.com/questions/6866578/python-and-gtk-how-to-
create-garbage-collector-friendly-objects?rq=1) but it does not help too much.


Answer: In short: yes, it does, dynamically created functions are created just like
any other Python objects created during run-time.

Longer answer: For resources managed by the garbage collector, such as objects
not tied to an external resource, Python and PyGTK will correctly dispose of
unused objects. For external resources, such as open files or running threads,
you need to take steps to ensure their correct cleanup. To answer your
question precisely, it would be useful to see concrete code. In general, the
following things apply to Python and GTK:

  * Python objects, including dynamically created functions, are deallocated some time after they can no longer be reached from Python. In some cases deallocation happens immediately after the object becomes unreachable (if the object is not involved in reference cycles), while in others you must wait for the garbage collector to kick in.

  * Destroying a widget causes GTK resources associated with the widget to be cleared immediately. The object itself can remain alive. Callbacks reachable through the widget should be dereferenced immediately and, provided nothing else holds on to them from Python, soon deallocated.

You can use the weak reference type from the `weakref` module to test this.
For example:

    
    
    >>> import gtk
    >>> 
    >>> def report_death(obj):
    ...     # arrange for the death of OBJ to be announced
    ...     def announce(wr):
    ...         print 'gone'
    ...     import weakref
    ...     report_death.wr = weakref.ref(obj, announce)
    ... 
    >>> def make_dynamic_handler():
    ...     def handler():
    ...         pass
    ...     # for debugging - we want to know when the handler is freed
    ...     report_death(handler)
    ...     return handler
    ... 
    >>> w = gtk.Window()
    >>> w.connect('realize', make_dynamic_handler())
    10L
    >>> w.destroy()
    gone
    

Now, if you change the code to `handler` to include a circular reference, e.g.
by modifying it to mention itself:

    
    
    def handler():
        handler      # closure with circular reference
    

...the call to destroy will no longer cause `gone` to be immediately printed -
that will require the program to keep working, or an explicit call to
`gc.collect()`. In most Python and PyGTK programs automatic deallocation "just
works" and you don't need to make an effort to help it.

Ultimately, the only **reliable** test whether there is a memory leak is
running the suspect code in an infinite loop and monitoring the memory
consumption of the process - if it grows without bounds, something is not
getting deallocated and you have a memory leak.

