Design thought for callbacks

[Chris Angelico]

On Sun, Feb 22, 2015 at 12:13 AM, Cem Karan <cfkaran2 at gmail.com> wrote:
> OK, so it would violate the principle of least surprise for you.  Interesting.  Is this a general pattern in python?  That is, callbacks are owned by what they are registered with?
>
> In the end, I want to make a library that offers as few surprises to the user as possible, and no matter how I think about callbacks, they are surprising to me.  If callbacks are strongly-held, then calling 'del foo' on a callable object may not make it go away, which can lead to weird and nasty situations.  Weakly-held callbacks mean that I (as the programmer), know that objects will go away after the next garbage collection (see Frank's earlier message), so I don't get 'dead' callbacks coming back from the grave to haunt me.
>
> So, what's the consensus on the list, strongly-held callbacks, or weakly-held ones?

I don't know about Python specifically, but it's certainly a general
pattern in other languages. They most definitely are owned, and it's
the only model that makes sense when you use closures (which won't
have any other references anywhere).

If you're expecting 'del foo' to destroy the object, then you have a
bigger problem than callbacks, because that's simply not how Python
works. You can't _ever_ assume that deleting something from your local
namespace will destroy the object, because there can always be more
references. So maybe you need a more clear way of saying "I'm done
with this, get rid of it".

ChrisA