Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!ecngs!feeder2.ecngs.de!novso.com!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <E5C0C060-4F1E-4656-BE58-E3D81D295B34@gmail.com>
References: <33677AE8-B2FA-49F9-9304-C8D93784255D@gmail.com> <mailman.18947.1424497301.18130.python-list@python.org> <54e8af1b$0$12976$c3e8da3$5496439d@news.astraweb.com> <mailman.18987.1424587462.18130.python-list@python.org> <cktoi3F7hlsU1@mid.individual.net> <E5C0C060-4F1E-4656-BE58-E3D81D295B34@gmail.com>
From: Ian Kelly <ian.g.kelly@gmail.com>
Date: Sun, 22 Feb 2015 23:57:04 -0700
Subject: Re: Design thought for callbacks
To: Python <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.19057.1424674675.18130.python-list@python.org>
Lines: 53
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:86198

On Sun, Feb 22, 2015 at 7:22 AM, Cem Karan <cfkaran2@gmail.com> wrote:
>
> On Feb 22, 2015, at 5:15 AM, Gregory Ewing <greg.ewing@canterbury.ac.nz> =
wrote:
>
>> Frank Millman wrote:
>>> "In order to inform users that certain bits of state have changed, I re=
quire them to register a callback with my code."
>>> This sounds to me like a pub/sub scenario. When a 'listener' object com=
es into existence it is passed a reference to a 'controller' object that ho=
lds state. It wants to be informed when the state changes, so it registers =
a callback function with the controller.
>>
>> Perhaps instead of registering a callback function, you
>> should be registering the listener object together with
>> a method name.
>>
>> You can then keep a weak reference to the listener object,
>> since if it is no longer referenced elsewhere, it presumably
>> no longer needs to be notified of anything.
>
> I see what you're saying, but I don't think it gains us too much.  If I s=
tore an object and an unbound method of the object, or if I store the bound=
 method directly, I suspect it will yield approximately the same results.

Well, it ties the weak ref to the lifetime of the object owning the
callback rather than to the lifetime of the potentially unreferenced
callback itself. I'm not fond of the scheme though because it forces
the callback to be a method, and I'd prefer not to make that
assumption.

Also, I just noticed that Python 3.4 adds a weakref.WeakMethod class
that solves the problem for the bound method case. That still leaves
the closure and lambda cases, but here's a thought: add an optional
argument to the callback registration method that specifies what
object to tie the weak ref to. Something like:

class Listenable:
    def __init__(self):
        self._callbacks =3D weakref.WeakKeyDictionary()

    def listen(self, callback, owner=3DNone):
        if owner is None:
            if isinstance(callback, types.MethodType):
                owner =3D weakref.WeakMethod(callback)
            else:
                owner =3D callback
        self._callbacks.setdefault(owner, []).append(callback)

    def do_callbacks(self, message):
        for callbacks in self._callbacks.values():
            for callback in callbacks:
                callback(message)