Design thought for callbacks
Cem Karan
cfkaran2 at gmail.com
Sun Feb 22 09:10:20 EST 2015
On Feb 22, 2015, at 7:52 AM, Laura Creighton <lac at openend.se> wrote:
> In a message of Sun, 22 Feb 2015 07:16:14 -0500, Cem Karan writes:
>
>> 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.
>
> 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
>
> especially the bottom of that.
>
> 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.
>
> 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
More information about the Python-list
mailing list