Design thought for callbacks
Frank Millman
frank at chagford.com
Sat Feb 21 00:41:14 EST 2015
"Cem Karan" <cfkaran2 at gmail.com> wrote in message
news:33677AE8-B2FA-49F9-9304-C8D93784255D at gmail.com...
> Hi all, I'm working on a project that will involve the use of callbacks,
> and I want to bounce an idea I had off of everyone to make sure I'm not
> developing a bad idea. Note that this is for python 3.4 code; I don't
> need to worry about any version of python earlier than that.
>
> 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?
>
I tried something similar a while ago, and I did find a gotcha.
The problem lies in this phrase - "if they are no longer alive, they are
automatically removed from the WeakSet, preventing me from accidentally
calling them when they are dead."
I found that the reference was not removed immediately, but was waiting to
be garbage collected. During that window, I could call the callback, which
resulted in an error.
There may have been a simple workaround. Perhaps someone else can comment.
Frank Millman
More information about the Python-list
mailing list