Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.albasani.net!newsreader4.netcologne.de!news.netcologne.de!bcyclone04.am1.xlned.com!bcyclone04.am1.xlned.com!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: Design thought for callbacks
From: Cem Karan <cfkaran2@gmail.com>
In-Reply-To: <CAPTjJmrA2suEdKDZkn44Xxsq4m_mZ=Jf6C19GvBjoBfCaTEyzg@mail.gmail.com>
Date: Sat, 21 Feb 2015 10:45:22 -0500
Content-Transfer-Encoding: quoted-printable
References: <33677AE8-B2FA-49F9-9304-C8D93784255D@gmail.com> <CAPTjJmpEHQV2PpaZvszuTGn0_GNg0sWV6aLenbQsZrSXCy2YKQ@mail.gmail.com> <39813568-6DB8-4341-A130-C256CFF352EE@gmail.com> <CAPTjJmrfMowbK7z+eN7xfMv2Ck5peJpBPyBRHvhXM4-ocxRR6w@mail.gmail.com> <BB15CAE6-4C31-4544-A9DE-DC9D6F827B45@gmail.com> <CAPTjJmrA2suEdKDZkn44Xxsq4m_mZ=Jf6C19GvBjoBfCaTEyzg@mail.gmail.com>
To: Chris Angelico <rosuav@gmail.com>
Cc: "comp.lang.python" <python-list@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.18972.1424533526.18130.python-list@python.org>
Lines: 94
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:86049


On Feb 21, 2015, at 9:36 AM, Chris Angelico <rosuav@gmail.com> wrote:

> On Sun, Feb 22, 2015 at 1:07 AM, Cem Karan <cfkaran2@gmail.com> wrote:
>> I agree about closures; its the only way they could work.  When I was =
originally thinking about the library, I was trying to include all types =
of callbacks, including closures and callable objects.  The callable =
objects may pass themselves, or one of their methods to the library, or =
may do something really weird.
>>=20
>> Although I just realized that closures may cause another problem.  In =
my code, I expect that many different callbacks can be registered for =
the same event.  Unregistering means you request to be unregistered for =
the event. How do you do that with a closure?  Aren't they anonymous?
>>=20
>=20
> They're objects, same as any other, so the caller can hang onto a
> reference and then say "now remove this one". Simple example:
>=20
> callbacks =3D []
> def register_callback(f): callbacks.append(f)
> def unregister_callback(f): callbacks.remove(f)
> def do_callbacks():
>    for f in callbacks:
>        f()
>=20
> def make_callback(i):
>    def inner():
>        print("Callback! %d"%i)
>    register_callback(inner)
>    return inner
>=20
> make_callback(5)
> remove_me =3D make_callback(6)
> make_callback(7)
> unregister_callback(remove_me)
> do_callbacks()

Yeah, that's pretty much what I thought you'd have to do, which kind of =
defeats the purpose of closures (fire-and-forget things).  BUT it does =
answer my question, so no complaints about it!

So, either you keep a reference to your own closure, which means that =
the library doesn't really need to, or the library keeps hold of it for =
you, in which case you don't have a reasonable way of removing it.

> The other option is for your callback registration to return some kind
> of identifier, which can later be used to unregister the callback.
> This is a good way of avoiding reference cycles (the ID could be a
> simple integer - maybe the length of the list prior to the new
> callback being appended, and then the unregistration process is simply
> "callbacks[id] =3D None", and you skip the Nones when iterating), and
> even allows you to register the exact same function more than once,
> for what that's worth.

That would work.  In the cases where someone might register & unregister =
many callbacks, you might use UUIDs as keys instead (avoids the ABA =
problem).

> When I do GUI programming, this is usually how things work. For
> instance, I use GTK2 (though usually with Pike rather than Python),
> and I can connect a signal to a callback function. Any given signal
> could have multiple callbacks attached to it, so it's similar to your
> case. I frequently depend on the GTK engine retaining a reference to
> my function (and thus to any data it requires), as I tend not to hang
> onto any inner objects that don't need retention. Once the parent
> object is destroyed, all its callbacks get dereferenced. Consider this
> simplified form:
>=20
> def popup_window():
>    w =3D Window()
>    # Add layout, info, whatever it takes
>    btn =3D Button("Close")
>    w.add(btn) # actually it'd be added to a layout
>    btn.signal_connect("clicked", lambda *args: w.destroy())
>=20
> The GUI back end will hang onto a reference to the window, because
> it's currently on screen; to the button, because it's attached to the
> window; and to my function, because it's connected to a button signal.
> Then when you click the button, the window gets destroyed, which
> destroys the button, which unregisters all its callbacks. At that
> point, there are no refs to the function, so it can get disposed of.
> That button function was the last external reference to the window,
> and now that it's not on screen, its Python object can also be
> disposed of, as can the button inside. So it'll all clean up fairly
> nicely; as long as the callback gets explicitly deregistered, that's
> the end of everything.

OK, so if I'm reading your code correctly, you're breaking the cycle in =
your object graph by making the GUI the owner of the callback, correct?  =
No other chunk of code has a reference to the callback, correct? =20

Thanks,
Cem Karan=