Design thought for callbacks

Cem Karan cfkaran2 at gmail.com
Mon Mar 2 06:04:33 EST 2015


On Feb 26, 2015, at 2:54 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Feb 26, 2015 4:00 AM, "Cem Karan" <cfkaran2 at gmail.com> wrote:
> >
> >
> > On Feb 26, 2015, at 12:36 AM, Gregory Ewing <greg.ewing at canterbury.ac.nz> wrote:
> >
> > > Cem Karan wrote:
> > >> I think I see what you're talking about now.  Does WeakMethod
> > >> (https://docs.python.org/3/library/weakref.html#weakref.WeakMethod) solve
> > >> this problem?
> > >
> > > Yes, that looks like it would work.
> >
> >
> > Cool!
> 
> Sometimes I wonder whether anybody reads my posts. I suggested a solution involving WeakMethod four days ago that additionally extends the concept to non-method callbacks (requiring a small amount of extra effort from the client in those cases, but I think that is unavoidable. There is no way that the framework can determine the appropriate lifetime for a closure-based callback.)

I apologize about taking so long to reply to everyone's posts, but I've been busy at home.

Ian, it took me a while to do some research to understand WHY what you were suggesting was important; you're right about storing the object as well as the method/function separately, but I think that WeakMethod might solve that completely, correct?  Are there any cases where WeakMethod wouldn't work?

Thanks,
Cem Karan


More information about the Python-list mailing list