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


Groups > comp.lang.python > #86106

Re: Design thought for callbacks

From Marko Rauhamaa <marko@pacujo.net>
Newsgroups comp.lang.python
Subject Re: Design thought for callbacks
Date 2015-02-22 14:46 +0200
Organization A noiseless patient Spider
Message-ID <87fv9y9krs.fsf@elektro.pacujo.net> (permalink)
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> <mailman.19003.1424607379.18130.python-list@python.org>

Show all headers | View raw


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.


Marko

Back to comp.lang.python | Previous | NextPrevious 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