Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #86123

Re: Design thought for callbacks

Show all headers | View raw

On Feb 22, 2015, at 7:46 AM, Marko Rauhamaa <marko@pacujo.net> wrote:

> Cem Karan <cfkaran2@gmail.com>:
> 
>> On Feb 21, 2015, at 12:08 PM, Marko Rauhamaa <marko@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 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.
> 
> When dealing with callbacks, my advice is to create your objects as
> explicit finite state machines. Don't try to encode the object state
> implicitly or indirectly. Rather, give each and every state a symbolic
> name and log the state transitions for troubleshooting.
> 
> Your callbacks should then consider what to do in each state. There are
> different ways to express this in Python, but it always boils down to a
> state/transition matrix.
> 
> Callbacks sometimes cannot be canceled after they have been committed to
> and have been shipped to the event pipeline. Then, the receiving object
> must brace itself for the impending spurious callback.

Nononono, I'm NOT encoding anything implicitly!  As Frank mentioned earlier, this is more of a pub/sub problem.  E.g., 'USB dongle has gotten plugged in', or 'key has been pressed'.  The user code needs to decide what to do next, the library code provides a nice, clean interface to some potentially weird hardware.

Thanks,
Cem Karan

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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