Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!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: <201502221252.t1MCq11A012613@fido.openend.se>
Date: Sun, 22 Feb 2015 09:10:20 -0500
Content-Transfer-Encoding: quoted-printable
References: <33677AE8-B2FA-49F9-9304-C8D93784255D@gmail.com> <mailman.18947.1424497301.18130.python-list@python.org> <54e8af1b$0$12976$c3e8da3$5496439d@news.astraweb.com> <87egpjtcp0.fsf@elektro.pacujo.net><5204A93E-8834-4C6E-9B6C-F885A4B3D89A@gmail.com> <201502221252.t1MCq11A012613@fido.openend.se>
To: Laura Creighton <lac@openend.se>
Cc: python-list@python.org
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.19013.1424614226.18130.python-list@python.org>
Lines: 41
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:86121


On Feb 22, 2015, at 7:52 AM, Laura Creighton <lac@openend.se> wrote:

> In a message of Sun, 22 Feb 2015 07:16:14 -0500, Cem Karan writes:
>=20
>> This was PRECISELY the situation I was thinking about.  My hope was
>> to make the callback mechanism slightly less surprising by allowing
>> the user to track them, releasing them when they aren't needed
>> without having to figure out where the callbacks were registered.
>> However, it appears I'm making things more surprising rather than
>> less.
>=20
> You may be able to accomplish your goal by using a Queue with a
> producer/consumer model.
> see: =
http://stackoverflow.com/questions/9968592/turn-functions-with-a-callback-=
into-python-generators
>=20
> especially the bottom of that.
>=20
> I haven't run the code, but it looks mostly reasonable, except that
> you do not want to rely on the Queue maxsize being 1 here, and
> indeed, I almost always want a bigger Queue  in any case.  Use
> Queue.task_done if blocking the producer features in your design.
>=20
> The problem that you are up against is that callbacks are inherantly
> confusing, even to programmers who are learning about them for the
> first time.  They don't fit people's internal model of 'how code =
works'.
> There isn't a whole lot one can do about that except to
> try to make the magic do as little as possible, so that more of the
> code works 'the way people expect'.

I think what you're suggesting is that library users register a Queue =
instead of a callback, correct?  The problem is that I'll then have a =
strong reference to the Queue, which means I'll be pumping events into =
it after the user code has gone away.  I was hoping to solve the problem =
of forgotten registrations in the library.

Thanks,
Cem Karan=