Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #86121
| Subject | Re: Design thought for callbacks |
|---|---|
| From | Cem Karan <cfkaran2@gmail.com> |
| Date | 2015-02-22 09:10 -0500 |
| 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> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.19013.1424614226.18130.python-list@python.org> (permalink) |
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: > >> 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
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: Design thought for callbacks "Frank Millman" <frank@chagford.com> - 2015-02-21 07:41 +0200
Re: Design thought for callbacks Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-22 03:15 +1100
Re: Design thought for callbacks Marko Rauhamaa <marko@pacujo.net> - 2015-02-21 19:08 +0200
Re: Design thought for callbacks Cem Karan <cfkaran2@gmail.com> - 2015-02-22 07:16 -0500
Re: Design thought for callbacks Marko Rauhamaa <marko@pacujo.net> - 2015-02-22 14:46 +0200
Re: Design thought for callbacks Cem Karan <cfkaran2@gmail.com> - 2015-02-22 09:17 -0500
Re: Design thought for callbacks Laura Creighton <lac@openend.se> - 2015-02-22 13:52 +0100
Re: Design thought for callbacks Cem Karan <cfkaran2@gmail.com> - 2015-02-22 09:10 -0500
Re: Design thought for callbacks "Frank Millman" <frank@chagford.com> - 2015-02-22 08:44 +0200
Re: Design thought for callbacks Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-02-22 23:15 +1300
Re: Design thought for callbacks Cem Karan <cfkaran2@gmail.com> - 2015-02-22 09:22 -0500
Re: Design thought for callbacks Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-02-24 18:45 +1300
Re: Design thought for callbacks Cem Karan <cfkaran2@gmail.com> - 2015-02-24 06:06 -0500
Re: Design thought for callbacks Ian Kelly <ian.g.kelly@gmail.com> - 2015-02-22 23:57 -0700
csiph-web