Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #86028

Re: Design thought for callbacks

Show all headers | View raw

On Feb 21, 2015, at 12:42 AM, Chris Angelico <rosuav@gmail.com> wrote:

> On Sat, Feb 21, 2015 at 1:44 PM, Cem Karan <cfkaran2@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.

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?

Thanks,
Cem Karan

Back to comp.lang.python | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Re: Design thought for callbacks Cem Karan <cfkaran2@gmail.com> - 2015-02-21 08:13 -0500
  Re: Design thought for callbacks Grant Edwards <invalid@invalid.invalid> - 2015-02-21 20:57 +0000
    Re: Design thought for callbacks Marko Rauhamaa <marko@pacujo.net> - 2015-02-21 23:57 +0200
      Re: Design thought for callbacks Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-22 13:04 +1100
        Re: Design thought for callbacks Chris Angelico <rosuav@gmail.com> - 2015-02-22 13:11 +1100
          Re: Design thought for callbacks Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-22 15:38 +1100
            Re: Design thought for callbacks Chris Angelico <rosuav@gmail.com> - 2015-02-22 17:21 +1100
              Re: Design thought for callbacks Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-22 21:32 +1100
                Re: Design thought for callbacks Chris Angelico <rosuav@gmail.com> - 2015-02-22 22:14 +1100
                Re: Design thought for callbacks Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-23 00:45 +1100
                Re: Design thought for callbacks Chris Angelico <rosuav@gmail.com> - 2015-02-23 01:01 +1100
        Re: Design thought for callbacks Marko Rauhamaa <marko@pacujo.net> - 2015-02-22 09:52 +0200
          Re: Design thought for callbacks Chris Angelico <rosuav@gmail.com> - 2015-02-22 19:17 +1100
            Re: Design thought for callbacks Marko Rauhamaa <marko@pacujo.net> - 2015-02-22 10:34 +0200
              Re: Design thought for callbacks Chris Angelico <rosuav@gmail.com> - 2015-02-22 19:58 +1100
                Re: Design thought for callbacks Marko Rauhamaa <marko@pacujo.net> - 2015-02-22 11:14 +0200
                Re: Design thought for callbacks Chris Angelico <rosuav@gmail.com> - 2015-02-22 21:21 +1100
                Re: Design thought for callbacks Laura Creighton <lac@openend.se> - 2015-02-22 12:28 +0100
                Re: Design thought for callbacks Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-23 00:57 +1100
                Re: Design thought for callbacks Marko Rauhamaa <marko@pacujo.net> - 2015-02-22 16:06 +0200
    Re: Design thought for callbacks Ian Kelly <ian.g.kelly@gmail.com> - 2015-02-22 00:05 -0700
    Re: Design thought for callbacks Cem Karan <cfkaran2@gmail.com> - 2015-02-22 08:21 -0500
      Re: Design thought for callbacks Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-02-24 18:20 +1300
        Re: Design thought for callbacks random832@fastmail.us - 2015-02-24 00:29 -0500
          Re: Design thought for callbacks Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-02-25 10:19 +1300
            Re: Design thought for callbacks Cem Karan <cfkaran2@gmail.com> - 2015-02-25 07:50 -0500
              Re: Design thought for callbacks Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-02-26 18:36 +1300
                Re: Design thought for callbacks Cem Karan <cfkaran2@gmail.com> - 2015-02-26 05:58 -0500
                Re: Design thought for callbacks Ian Kelly <ian.g.kelly@gmail.com> - 2015-02-26 12:54 -0700
                Re: Design thought for callbacks Ethan Furman <ethan@stoneleaf.us> - 2015-02-26 12:00 -0800
                Re: Design thought for callbacks Cem Karan <cfkaran2@gmail.com> - 2015-03-02 06:06 -0500
                Re: Design thought for callbacks Cem Karan <cfkaran2@gmail.com> - 2015-03-02 06:04 -0500
                Re: Design thought for callbacks Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-02 08:34 -0700
                Re: Design thought for callbacks Cem Karan <cfkaran2@gmail.com> - 2015-03-08 14:30 -0400

csiph-web