Re: Design thought for callbacks

2015-03-08 Thread Cem Karan
Hi all, I apologize for taking so long to reply, but neither my work schedule nor the weather have been kind in the past week. That said, I've been thinking long and hard about what everyone has said, and have decided that it would be useful to write a wrap-up email that attempts to

Re: Design thought for callbacks

2015-03-02 Thread Cem Karan
On Feb 26, 2015, at 7:04 PM, Fabio Zadrozny fabi...@gmail.com wrote: On Wed, Feb 25, 2015 at 9:46 AM, Cem Karan cfkar...@gmail.com wrote: On Feb 24, 2015, at 8:23 AM, Fabio Zadrozny fabi...@gmail.com wrote: Hi Cem, I didn't read the whole long thread, but I thought I'd point you to

Re: Design thought for callbacks

2015-03-02 Thread Cem Karan
On Feb 26, 2015, at 2:54 PM, Ian Kelly ian.g.ke...@gmail.com wrote: On Feb 26, 2015 4:00 AM, Cem Karan cfkar...@gmail.com wrote: On Feb 26, 2015, at 12:36 AM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: Cem Karan wrote: I think I see what you're talking about now. Does

Re: Design thought for callbacks

2015-03-02 Thread Cem Karan
On Feb 26, 2015, at 3:00 PM, Ethan Furman et...@stoneleaf.us wrote: On 02/26/2015 11:54 AM, Ian Kelly wrote: Sometimes I wonder whether anybody reads my posts. It's entirely possible the OP wasn't ready to understand your solution four days ago, but two days later the OP was. Thank you

Re: Design thought for callbacks

2015-03-02 Thread Ian Kelly
On Mon, Mar 2, 2015 at 4:04 AM, Cem Karan cfkar...@gmail.com wrote: On Feb 26, 2015, at 2:54 PM, Ian Kelly ian.g.ke...@gmail.com wrote: On Feb 26, 2015 4:00 AM, Cem Karan cfkar...@gmail.com wrote: On Feb 26, 2015, at 12:36 AM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: Cem

Re: Design thought for callbacks

2015-02-26 Thread Ethan Furman
On 02/26/2015 11:54 AM, Ian Kelly wrote: Sometimes I wonder whether anybody reads my posts. It's entirely possible the OP wasn't ready to understand your solution four days ago, but two days later the OP was. -- ~Ethan~ signature.asc Description: OpenPGP digital signature --

Re: Design thought for callbacks

2015-02-26 Thread Ian Kelly
On Feb 26, 2015 4:00 AM, Cem Karan cfkar...@gmail.com wrote: On Feb 26, 2015, at 12:36 AM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: Cem Karan wrote: I think I see what you're talking about now. Does WeakMethod (https://docs.python.org/3/library/weakref.html#weakref.WeakMethod)

Re: Design thought for callbacks

2015-02-26 Thread Cem Karan
On Feb 26, 2015, at 12:36 AM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: Cem Karan wrote: I think I see what you're talking about now. Does WeakMethod (https://docs.python.org/3/library/weakref.html#weakref.WeakMethod) solve this problem? Yes, that looks like it would work. Cool!

Re: Design thought for callbacks

2015-02-26 Thread Fabio Zadrozny
On Wed, Feb 25, 2015 at 9:46 AM, Cem Karan cfkar...@gmail.com wrote: On Feb 24, 2015, at 8:23 AM, Fabio Zadrozny fabi...@gmail.com wrote: Hi Cem, I didn't read the whole long thread, but I thought I'd point you to what I'm using in PyVmMonitor (http://www.pyvmmonitor.com/) -- which may

Re: Design thought for callbacks

2015-02-25 Thread Cem Karan
On Feb 24, 2015, at 4:19 PM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: random...@fastmail.us wrote: On Tue, Feb 24, 2015, at 00:20, Gregory Ewing wrote: This is why I suggested registering a listener object plus a method name instead of a callback. It avoids that reference cycle,

Re: Design thought for callbacks

2015-02-25 Thread Cem Karan
On Feb 24, 2015, at 8:23 AM, Fabio Zadrozny fabi...@gmail.com wrote: Hi Cem, I didn't read the whole long thread, but I thought I'd point you to what I'm using in PyVmMonitor (http://www.pyvmmonitor.com/) -- which may already cover your use-case. Take a look at the callback.py at

Re: Design thought for callbacks

2015-02-25 Thread Gregory Ewing
Cem Karan wrote: I think I see what you're talking about now. Does WeakMethod (https://docs.python.org/3/library/weakref.html#weakref.WeakMethod) solve this problem? Yes, that looks like it would work. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: Design thought for callbacks

2015-02-24 Thread Gregory Ewing
random...@fastmail.us wrote: On Tue, Feb 24, 2015, at 00:20, Gregory Ewing wrote: This is why I suggested registering a listener object plus a method name instead of a callback. It avoids that reference cycle, because there is no long-lived callback object keeping a reference to the listener.

Re: Design thought for callbacks

2015-02-24 Thread Cem Karan
I'm combining two messages into one, On Feb 24, 2015, at 12:29 AM, random...@fastmail.us wrote: On Tue, Feb 24, 2015, at 00:20, Gregory Ewing wrote: Cem Karan wrote: I tend to structure my code as a tree or DAG of objects. The owner refers to the owned object, but the owned object has no

Re: Design thought for callbacks

2015-02-24 Thread Cem Karan
On Feb 23, 2015, at 7:29 AM, Frank Millman fr...@chagford.com wrote: Cem Karan cfkar...@gmail.com wrote in message news:a3c11a70-5846-4915-bb26-b23793b65...@gmail.com... Good questions! That was why I was asking about 'gotchas' with WeakSets originally. Honestly, the only way to

Re: Design thought for callbacks

2015-02-23 Thread Steven D'Aprano
Cem Karan wrote: On Feb 21, 2015, at 12:27 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: The simplest possible identity-based scheme would be something like this: # don't hate me for using a global variable CALLBACKS = [] def register(func): if func not in

Re: Design thought for callbacks

2015-02-23 Thread Frank Millman
Cem Karan cfkar...@gmail.com wrote in message news:a3c11a70-5846-4915-bb26-b23793b65...@gmail.com... Good questions! That was why I was asking about 'gotchas' with WeakSets originally. Honestly, the only way to know for sure would be to write two APIs for doing similar things, and then

Re: Design thought for callbacks

2015-02-23 Thread Cem Karan
On Feb 22, 2015, at 5:29 PM, Laura Creighton l...@openend.se wrote: In a message of Sun, 22 Feb 2015 17:09:01 -0500, Cem Karan writes: Documentation is a given; it MUST be there. That said, documenting something, but still making it surprising, is a bad idea. For example, several people

Re: Design thought for callbacks

2015-02-23 Thread Gregory Ewing
Cem Karan wrote: I tend to structure my code as a tree or DAG of objects. The owner refers to the owned object, but the owned object has no reference to its owner. With callbacks, you get cycles, where the owned owns the owner. This is why I suggested registering a listener object plus a

Re: Design thought for callbacks

2015-02-22 Thread Cem Karan
On Feb 21, 2015, at 12:08 PM, Marko Rauhamaa ma...@pacujo.net wrote: Steven D'Aprano steve+comp.lang.pyt...@pearwood.info: Other than that, I cannot see how calling a function which has *not* yet been garbage collected can fail, just because the only reference still existing is a weak

Re: Design thought for callbacks

2015-02-22 Thread Marko Rauhamaa
Cem Karan cfkar...@gmail.com: On Feb 21, 2015, at 12:08 PM, Marko Rauhamaa ma...@pacujo.net wrote: Maybe the logic of the receiving object isn't prepared for the callback anymore after an intervening event. The problem then, of course, is in the logic and not in the callbacks. This was

Re: Design thought for callbacks

2015-02-22 Thread Cem Karan
On Feb 21, 2015, at 12:27 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Cem Karan wrote: On Feb 21, 2015, at 8:15 AM, Chris Angelico ros...@gmail.com wrote: On Sun, Feb 22, 2015 at 12:13 AM, Cem Karan cfkar...@gmail.com wrote: OK, so it would violate the principle of

Re: Design thought for callbacks

2015-02-22 Thread Cem Karan
On Feb 22, 2015, at 7:12 AM, Marko Rauhamaa ma...@pacujo.net wrote: Cem Karan cfkar...@gmail.com: On Feb 21, 2015, at 11:03 AM, Marko Rauhamaa ma...@pacujo.net wrote: I use callbacks all the time but haven't had any problems with strong references. I am careful to move my objects to a

Re: Design thought for callbacks

2015-02-22 Thread Marko Rauhamaa
Cem Karan cfkar...@gmail.com: You were saying that you move your objects into a zombie state. I assumed that you meant you marked them in some manner (e.g., setting 'is_zombie' to True), Yes, but even better: self.set_state(ZOMBIE) so that anything that has a strong reference to the

Re: Design thought for callbacks

2015-02-22 Thread Cem Karan
On Feb 22, 2015, at 7:24 AM, Chris Angelico ros...@gmail.com wrote: On Sun, Feb 22, 2015 at 11:07 PM, Cem Karan cfkar...@gmail.com wrote: Correct. The GUI engine ultimately owns everything. Of course, this is a very simple case (imagine a little notification popup; you don't care about it,

Re: Design thought for callbacks

2015-02-22 Thread Steven D'Aprano
Marko Rauhamaa wrote: Chris Angelico ros...@gmail.com: On Sun, Feb 22, 2015 at 7:34 PM, Marko Rauhamaa ma...@pacujo.net wrote: Refloops are not to be worried about, let alone removed. Why? Because the whole point of GC-languages is that you should stop worrying about memory. Trying to

Re: Design thought for callbacks

2015-02-22 Thread Marko Rauhamaa
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info: I don't know about Java's Hotspot, but I do know that CPython's ref counting garbage collector has at least one advantage over the GC used by Jython and IronPython: unlike them, open files are closed as soon as they are no longer in use.

Re: Design thought for callbacks

2015-02-22 Thread Cem Karan
On Feb 22, 2015, at 7:46 AM, Marko Rauhamaa ma...@pacujo.net wrote: Cem Karan cfkar...@gmail.com: On Feb 21, 2015, at 12:08 PM, Marko Rauhamaa ma...@pacujo.net wrote: Maybe the logic of the receiving object isn't prepared for the callback anymore after an intervening event. The problem

Re: Design thought for callbacks

2015-02-22 Thread Cem Karan
On Feb 22, 2015, at 5:15 AM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: Frank Millman wrote: In order to inform users that certain bits of state have changed, I require them to register a callback with my code. This sounds to me like a pub/sub scenario. When a 'listener' object comes

Re: Design thought for callbacks

2015-02-22 Thread Chris Angelico
On Sun, Feb 22, 2015 at 11:07 PM, Cem Karan cfkar...@gmail.com wrote: Correct. The GUI engine ultimately owns everything. Of course, this is a very simple case (imagine a little notification popup; you don't care about it, you don't need to know when it's been closed, the only event on it is

Re: Design thought for callbacks

2015-02-22 Thread Cem Karan
On Feb 21, 2015, at 11:03 AM, Marko Rauhamaa ma...@pacujo.net wrote: Chris Angelico ros...@gmail.com: On Sat, Feb 21, 2015 at 1:44 PM, Cem Karan cfkar...@gmail.com wrote: In order to inform users that certain bits of state have changed, I require them to register a callback with my code.

Re: Design thought for callbacks

2015-02-22 Thread Cem Karan
On Feb 21, 2015, at 3:57 PM, Grant Edwards invalid@invalid.invalid wrote: On 2015-02-21, Cem Karan cfkar...@gmail.com wrote: On Feb 21, 2015, at 12:42 AM, Chris Angelico ros...@gmail.com wrote: On Sat, Feb 21, 2015 at 1:44 PM, Cem Karan cfkar...@gmail.com wrote: In order to inform users

Re: Design thought for callbacks

2015-02-22 Thread Chris Angelico
On Sun, Feb 22, 2015 at 8:14 PM, Marko Rauhamaa ma...@pacujo.net wrote: Helping it along means your program doesn't waste memory. Why such a blanket statement? Because worrying Python programmers with evil spirits (reference loops) leads to awkward coding practices and takes away one of the

Re: Design thought for callbacks

2015-02-22 Thread Steven D'Aprano
Chris Angelico wrote: On Sun, Feb 22, 2015 at 3:38 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: But you are using it. You might not be using it by name, but you are using it via the callback function. What did you expect, that Python should read your mind and somehow

Re: Design thought for callbacks

2015-02-22 Thread Chris Angelico
On Sun, Feb 22, 2015 at 9:32 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Why? Do you expect that the Python garbage collector special cases callbacks to keep them alive even when there are no references to them? How would it distinguish a callback from some other function?

Re: Design thought for callbacks

2015-02-22 Thread Laura Creighton
somebody, I got confused with the indent level wrote: They force the use of the much slower cycle-detecting GC, rather than the quick and efficient CPython refcounter. Somebody has misunderstood something here. When it comes to efficient garbage collectors, refcounting is a turtle. The

Re: Design thought for callbacks

2015-02-22 Thread Cem Karan
On Feb 21, 2015, at 10:55 AM, Chris Angelico ros...@gmail.com wrote: On Sun, Feb 22, 2015 at 2:45 AM, Cem Karan cfkar...@gmail.com wrote: 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

Re: Design thought for callbacks

2015-02-22 Thread Marko Rauhamaa
Cem Karan cfkar...@gmail.com: On Feb 21, 2015, at 11:03 AM, Marko Rauhamaa ma...@pacujo.net wrote: I use callbacks all the time but haven't had any problems with strong references. I am careful to move my objects to a zombie state after they're done so they can absorb any potential loose

Re: Design thought for callbacks

2015-02-22 Thread Steven D'Aprano
Chris Angelico wrote: On Sun, Feb 22, 2015 at 9:32 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Why? Do you expect that the Python garbage collector special cases callbacks to keep them alive even when there are no references to them? How would it distinguish a callback

Re: Design thought for callbacks

2015-02-22 Thread Chris Angelico
On Mon, Feb 23, 2015 at 12:45 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: No no no. It's the other way around. _Something_ has to be doing those callbacks, and it's that _something_ that should be keeping them alive. The fact that it's a registered callback should itself

Re: Design thought for callbacks

2015-02-22 Thread Cem Karan
On Feb 22, 2015, at 7:52 AM, Laura Creighton l...@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

Re: Design thought for callbacks

2015-02-22 Thread Gregory Ewing
Frank Millman wrote: In order to inform users that certain bits of state have changed, I require them to register a callback with my code. This sounds to me like a pub/sub scenario. When a 'listener' object comes into existence it is passed a reference to a 'controller' object that holds

Re: Design thought for callbacks

2015-02-22 Thread Laura Creighton
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

Re: Design thought for callbacks

2015-02-22 Thread Chris Angelico
On Sun, Feb 22, 2015 at 6:52 PM, Marko Rauhamaa ma...@pacujo.net wrote: What I mean, though, is that you shouldn't think you need to create object destructors where you routinely set all members to None. Sure, not *routinely*. It'd be a special case where it's not specifically a destructor, and

Re: Design thought for callbacks

2015-02-22 Thread Marko Rauhamaa
Chris Angelico ros...@gmail.com: Or (a very common case for me) a callback saying remote end is gone (eg on a socket) might wipe out the callbacks, thus removing their refloops. Refloops are not to be worried about, let alone removed. Marko --

Re: Design thought for callbacks

2015-02-22 Thread Chris Angelico
On Sun, Feb 22, 2015 at 7:34 PM, Marko Rauhamaa ma...@pacujo.net wrote: Chris Angelico ros...@gmail.com: Or (a very common case for me) a callback saying remote end is gone (eg on a socket) might wipe out the callbacks, thus removing their refloops. Refloops are not to be worried about, let

Re: Design thought for callbacks

2015-02-22 Thread Marko Rauhamaa
Chris Angelico ros...@gmail.com: On Sun, Feb 22, 2015 at 7:34 PM, Marko Rauhamaa ma...@pacujo.net wrote: Refloops are not to be worried about, let alone removed. Why? Because the whole point of GC-languages is that you should stop worrying about memory. Trying to mastermind and micromanage

Re: Design thought for callbacks

2015-02-22 Thread Chris Angelico
On Mon, Feb 23, 2015 at 9:29 AM, Laura Creighton l...@openend.se wrote: But that is not so surprising. How many people use WeakSets for _anything_? I've never used them, aside from 'ooh! cool shiny new language feature! Let's kick it around the park!' That people aren't familiar with

Re: Design thought for callbacks

2015-02-22 Thread Ethan Furman
On 02/22/2015 05:13 AM, Cem Karan wrote: Output: From Evil Zombie: Surprise! From Your Significant Other: Surprise! In this case, the user made an error (just as Marko said in his earlier message), and forgot about the callback he registered with the library. The callback isn't

Re: Design thought for callbacks

2015-02-22 Thread Marko Rauhamaa
Cem Karan cfkar...@gmail.com: My goal is to make things as pythonic (whatever that means in this case) and obvious as possible. Ideally, a novice can more or less guess what will happen with my API without really having to read the documentation on it. If you try to shield your user from the

Re: Design thought for callbacks

2015-02-22 Thread Cem Karan
On Feb 22, 2015, at 4:34 PM, Marko Rauhamaa ma...@pacujo.net wrote: Cem Karan cfkar...@gmail.com: My goal is to make things as pythonic (whatever that means in this case) and obvious as possible. Ideally, a novice can more or less guess what will happen with my API without really having to

Re: Design thought for callbacks

2015-02-22 Thread Laura Creighton
In a message of Sun, 22 Feb 2015 17:09:01 -0500, Cem Karan writes: Documentation is a given; it MUST be there. That said, documenting something, but still making it surprising, is a bad idea. For example, several people have been strongly against using a WeakSet to hold callbacks because they

Re: Design thought for callbacks

2015-02-22 Thread Cem Karan
On Feb 22, 2015, at 4:02 PM, Ethan Furman et...@stoneleaf.us wrote: On 02/22/2015 05:13 AM, Cem Karan wrote: Output: From Evil Zombie: Surprise! From Your Significant Other: Surprise! In this case, the user made an error (just as Marko said in his earlier message), and forgot about

Re: Design thought for callbacks

2015-02-22 Thread Ian Kelly
On Sun, Feb 22, 2015 at 7:22 AM, Cem Karan cfkar...@gmail.com wrote: On Feb 22, 2015, at 5:15 AM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: Frank Millman wrote: In order to inform users that certain bits of state have changed, I require them to register a callback with my code.

Re: Design thought for callbacks

2015-02-21 Thread Chris Angelico
On Sun, Feb 22, 2015 at 1:04 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Marko Rauhamaa wrote: Grant Edwards invalid@invalid.invalid: the polite thing to do is to delete references to it when you're done with it. I disagree with that recommendation. You should do the

Re: Design thought for callbacks

2015-02-21 Thread Marko Rauhamaa
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info: Marko Rauhamaa wrote: Grant Edwards invalid@invalid.invalid: the polite thing to do is to delete references to it when you're done with it. I disagree with that recommendation. You should do the natural thing and not care who holds

Re: Design thought for callbacks

2015-02-21 Thread Marko Rauhamaa
Grant Edwards invalid@invalid.invalid: the polite thing to do is to delete references to it when you're done with it. I disagree with that recommendation. You should do the natural thing and not care who holds references to who. Marko -- https://mail.python.org/mailman/listinfo/python-list

Re: Design thought for callbacks

2015-02-21 Thread Ian Kelly
On Sat, Feb 21, 2015 at 1:57 PM, Grant Edwards invalid@invalid.invalid wrote: On 2015-02-21, Cem Karan cfkar...@gmail.com wrote: On Feb 21, 2015, at 12:42 AM, Chris Angelico ros...@gmail.com wrote: On Sat, Feb 21, 2015 at 1:44 PM, Cem Karan cfkar...@gmail.com wrote: In order to inform users

Re: Design thought for callbacks

2015-02-21 Thread Chris Angelico
On Sun, Feb 22, 2015 at 3:38 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: But you are using it. You might not be using it by name, but you are using it via the callback function. What did you expect, that Python should read your mind and somehow intuit that you still care

Re: Design thought for callbacks

2015-02-21 Thread Steven D'Aprano
Chris Angelico wrote: On Sun, Feb 22, 2015 at 1:04 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Marko Rauhamaa wrote: Grant Edwards invalid@invalid.invalid: the polite thing to do is to delete references to it when you're done with it. I disagree with that

Re: Design thought for callbacks

2015-02-21 Thread Steven D'Aprano
Marko Rauhamaa wrote: Grant Edwards invalid@invalid.invalid: the polite thing to do is to delete references to it when you're done with it. I disagree with that recommendation. You should do the natural thing and not care who holds references to who. I don't understand this. What is the

Re: Design thought for callbacks

2015-02-21 Thread Frank Millman
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote in message news:54e8af1b$0$12976$c3e8da3$54964...@news.astraweb.com... Frank Millman wrote: I tried something similar a while ago, and I did find a gotcha. The problem lies in this phrase - if they are no longer alive, they are

Re: Design thought for callbacks

2015-02-21 Thread Cem Karan
On Feb 21, 2015, at 9:36 AM, Chris Angelico ros...@gmail.com wrote: On Sun, Feb 22, 2015 at 1:07 AM, Cem Karan cfkar...@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

Re: Design thought for callbacks

2015-02-21 Thread Chris Angelico
On Sun, Feb 22, 2015 at 2:45 AM, Cem Karan cfkar...@gmail.com wrote: 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? Correct. The

Re: Design thought for callbacks

2015-02-21 Thread Marko Rauhamaa
Chris Angelico ros...@gmail.com: On Sat, Feb 21, 2015 at 1:44 PM, Cem Karan cfkar...@gmail.com wrote: In order to inform users that certain bits of state have changed, I require them to register a callback with my code. The problem is that when I store these callbacks, it naturally creates a

Re: Design thought for callbacks

2015-02-21 Thread Steven D'Aprano
Frank Millman wrote: I tried something similar a while ago, and I did find a gotcha. The problem lies in this phrase - if they are no longer alive, they are automatically removed from the WeakSet, preventing me from accidentally calling them when they are dead. I found that the reference

Re: Design thought for callbacks

2015-02-21 Thread Steven D'Aprano
Cem Karan wrote: On Feb 21, 2015, at 8:15 AM, Chris Angelico ros...@gmail.com wrote: On Sun, Feb 22, 2015 at 12:13 AM, Cem Karan cfkar...@gmail.com wrote: OK, so it would violate the principle of least surprise for you. Interesting. Is this a general pattern in python? That is,

Re: Design thought for callbacks

2015-02-21 Thread Marko Rauhamaa
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info: Other than that, I cannot see how calling a function which has *not* yet been garbage collected can fail, just because the only reference still existing is a weak reference. Maybe the logic of the receiving object isn't prepared for the

Re: Design thought for callbacks

2015-02-21 Thread Cem Karan
On Feb 21, 2015, at 12:42 AM, Chris Angelico ros...@gmail.com wrote: On Sat, Feb 21, 2015 at 1:44 PM, Cem Karan cfkar...@gmail.com wrote: In order to inform users that certain bits of state have changed, I require them to register a callback with my code. The problem is that when I store

Re: Design thought for callbacks

2015-02-21 Thread Mark Lawrence
On 21/02/2015 05:41, Frank Millman wrote: Cem Karan cfkar...@gmail.com wrote in message news:33677ae8-b2fa-49f9-9304-c8d937842...@gmail.com... Hi all, I'm working on a project that will involve the use of callbacks, and I want to bounce an idea I had off of everyone to make sure I'm not

Re: Design thought for callbacks

2015-02-21 Thread Cem Karan
On Feb 21, 2015, at 8:15 AM, Chris Angelico ros...@gmail.com wrote: On Sun, Feb 22, 2015 at 12:13 AM, Cem Karan cfkar...@gmail.com wrote: OK, so it would violate the principle of least surprise for you. Interesting. Is this a general pattern in python? That is, callbacks are owned by

Re: Design thought for callbacks

2015-02-21 Thread Devin Jeanpierre
On Fri, Feb 20, 2015 at 9:42 PM, Chris Angelico ros...@gmail.com wrote: No, it's not. I would advise using strong references - if the callback is a closure, for instance, you need to hang onto it, because there are unlikely to be any other references to it. If I register a callback with you, I

Re: Design thought for callbacks

2015-02-21 Thread Chris Angelico
On Sun, Feb 22, 2015 at 12:13 AM, Cem Karan cfkar...@gmail.com wrote: OK, so it would violate the principle of least surprise for you. Interesting. Is this a general pattern in python? That is, callbacks are owned by what they are registered with? In the end, I want to make a library

Re: Design thought for callbacks

2015-02-21 Thread Cem Karan
On Feb 21, 2015, at 12:41 AM, Frank Millman fr...@chagford.com wrote: Cem Karan cfkar...@gmail.com wrote in message news:33677ae8-b2fa-49f9-9304-c8d937842...@gmail.com... Hi all, I'm working on a project that will involve the use of callbacks, and I want to bounce an idea I had off of

Re: Design thought for callbacks

2015-02-21 Thread Cem Karan
On Feb 21, 2015, at 8:37 AM, Mark Lawrence breamore...@yahoo.co.uk wrote: On 21/02/2015 05:41, Frank Millman wrote: Cem Karan cfkar...@gmail.com wrote in message news:33677ae8-b2fa-49f9-9304-c8d937842...@gmail.com... Hi all, I'm working on a project that will involve the use of callbacks,

Re: Design thought for callbacks

2015-02-21 Thread Chris Angelico
On Sun, Feb 22, 2015 at 1:07 AM, Cem Karan cfkar...@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

Re: Design thought for callbacks

2015-02-21 Thread Grant Edwards
On 2015-02-21, Cem Karan cfkar...@gmail.com wrote: On Feb 21, 2015, at 12:42 AM, Chris Angelico ros...@gmail.com wrote: On Sat, Feb 21, 2015 at 1:44 PM, Cem Karan cfkar...@gmail.com wrote: In order to inform users that certain bits of state have changed, I require them to register a

Design thought for callbacks

2015-02-20 Thread Cem Karan
Hi all, I'm working on a project that will involve the use of callbacks, and I want to bounce an idea I had off of everyone to make sure I'm not developing a bad idea. Note that this is for python 3.4 code; I don't need to worry about any version of python earlier than that. In order to

Re: Design thought for callbacks

2015-02-20 Thread Chris Angelico
On Sat, Feb 21, 2015 at 1:44 PM, Cem Karan cfkar...@gmail.com wrote: In order to inform users that certain bits of state have changed, I require them to register a callback with my code. The problem is that when I store these callbacks, it naturally creates a strong reference to the objects,

Re: Design thought for callbacks

2015-02-20 Thread Frank Millman
Cem Karan cfkar...@gmail.com wrote in message news:33677ae8-b2fa-49f9-9304-c8d937842...@gmail.com... Hi all, I'm working on a project that will involve the use of callbacks, and I want to bounce an idea I had off of everyone to make sure I'm not developing a bad idea. Note that this is for