Design thought for callbacks

[Cem Karan]

On Feb 22, 2015, at 4:02 PM, Ethan Furman <ethan at 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 the callback he registered with the library.  The callback isn't
>> really rising from the dead; as you say, either its been garbage collected, or it
>> hasn't been.  However, you may not be ready for a callback to be called at that
>> moment in time, which means you're surprised by unexpected behavior.
> 
> But the unexpected behavior is not a problem with Python, nor with your library -- it's a bug in the fellow-programmer's
> code, and you can't (or at least shouldn't) try to prevent those kinds of bugs from manifesting -- they'll just get
> bitten somewhere else by the same bug.

I agree with you, but until a relatively new programmer has gotten used to what callbacks are and what they imply, I want to make things easy.  For example, if the API subclasses collections.abc.MutableSet, and the documentation states that you can only add callbacks to this particular type of set, then a new programmer will naturally decide that either a) they need to dispose of the set, and if that isn't possible, then b) they need to delete their callback from the set.  It won't occur to them that their live object will just magically 'go away'; its a member of a set!

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.  

Thanks,
Cem Karan