Design thought for callbacks

Chris Angelico rosuav at gmail.com
Sat Feb 21 00:42:58 EST 2015


On Sat, Feb 21, 2015 at 1:44 PM, Cem Karan <cfkaran2 at gmail.com> wrote:
> In order to inform users that certain bits of state have changed, I require them to register a callback with my code.  The problem is that when I store these callbacks, it naturally creates a strong reference to the objects, which means that if they are deleted without unregistering themselves first, my code will keep the callbacks alive.  Since this could lead to really weird and nasty situations, I would like to store all the callbacks in a WeakSet (https://docs.python.org/3/library/weakref.html#weakref.WeakSet).  That way, my code isn't the reason why the objects are kept alive, and if they are no longer alive, they are automatically removed from the WeakSet, preventing me from accidentally calling them when they are dead.  My question is simple; is this a good design?  If not, why not?  Are there any potential 'gotchas' I should be worried about?
>

No, it's not. I would advise using strong references - if the callback
is a closure, for instance, you need to hang onto it, because there
are unlikely to be any other references to it. If I register a
callback with you, I expect it to be called; I expect, in fact, that
that *will* keep my object alive.

ChrisA



More information about the Python-list mailing list