Path: csiph.com!usenet.pasdenom.info!gegeweb.org!usenet-fr.net!nerim.net!novso.com!newsfeed.xs4all.nl!newsfeed2a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.002 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'python,': 0.02; 'encoding': 0.05; 'shipped': 0.05; '21,': 0.07; 'explicit': 0.07; '22,': 0.09; 'callback': 0.09; 'e.g.,': 0.09; 'encode': 0.09; 'logic': 0.09; 'machines.': 0.09; 'next,': 0.09; 'cc:addr:python- list': 0.11; 'brace': 0.16; 'canceled': 0.16; 'finite': 0.16; 'hardware.': 0.16; 'intervening': 0.16; 'rather,': 0.16; 'registered.': 0.16; 'spurious': 0.16; 'surprising': 0.16; 'weird': 0.16; 'thanks,': 0.17; 'wrote:': 0.18; 'library': 0.18; 'mechanism': 0.19; 'slightly': 0.19; 'feb': 0.22; '>>>': 0.22; 'appears': 0.22; 'cc:addr:python.org': 0.22; "aren't": 0.24; 'decide': 0.24; 'cc:2**0': 0.24; 'cc:no real name:2**0': 0.24; 'header:In-Reply-To:1': 0.27; 'am,': 0.29; "i'm": 0.30; 'code': 0.31; 'about.': 0.31; 'releasing': 0.31; 'symbolic': 0.31; 'figure': 0.32; 'interface': 0.32; 'maybe': 0.34; 'problem': 0.35; 'advice': 0.35; 'problem.': 0.35; 'objects': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'there': 0.35; 'charset:us-ascii': 0.36; 'should': 0.36; 'sometimes': 0.38; 'message-id:@gmail.com': 0.38; 'needed': 0.38; 'pm,': 0.38; 'track': 0.38; 'rather': 0.38; 'anything': 0.39; 'itself': 0.39; 'event.': 0.60; 'then,': 0.60; 'hope': 0.61; 'mentioned': 0.61; 'making': 0.63; 'header:Message- Id:1': 0.63; 'name': 0.63; 'more': 0.64; 'different': 0.65; 'situation': 0.65; 'frank': 0.68; 'gotten': 0.74; 'subject:Design': 0.78; 'potentially': 0.81; 'dongle': 0.84; 'matrix.': 0.84; 'nice,': 0.84; 'subject:thought': 0.84; 'state.': 0.95 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zLfqXJOC240V1aHhXVHEU6uPaFtj3E5Qoa9XxRF7MyQ=; b=zI7Uu8cKNqfQ3vdK7qmbBbWD90IuYoxOjlV1MTgMIiG/Hv3t847tKKjP3EV3pGf/lz WdoSBBaaMnMqJJfX1YAroYZCBPJ99P1iyan72No0iVUtWJ67FhX3OBZosQX44O36fkel y/STM4b1Cjj3m+BZocSNn7prpArJlkEcoPYx8bkHmeW816Rf9RWaUWCB0BDvyj5E93DN fvO6000/O2Glnhboy8TNjK+LxO4oFaPFoA3koul3EkwIQoPmlJ0nAvhdBeVW8RPDGYsg lOqeuHZklRF0G7Rr7TbjZ+cogKqUivUpF6cZJuBt5twtf//Wc2vQmeWAOZFYowMwEKMX FyWQ== X-Received: by 10.52.52.136 with SMTP id t8mr6321991vdo.49.1424614665120; Sun, 22 Feb 2015 06:17:45 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Design thought for callbacks From: Cem Karan In-Reply-To: <87fv9y9krs.fsf@elektro.pacujo.net> Date: Sun, 22 Feb 2015 09:17:41 -0500 Content-Transfer-Encoding: quoted-printable References: <33677AE8-B2FA-49F9-9304-C8D93784255D@gmail.com> <54e8af1b$0$12976$c3e8da3$5496439d@news.astraweb.com> <87egpjtcp0.fsf@elektro.pacujo.net> <87fv9y9krs.fsf@elektro.pacujo.net> To: Marko Rauhamaa X-Mailer: Apple Mail (2.1510) Cc: python-list@python.org X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 45 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1424614667 news.xs4all.nl 2899 [2001:888:2000:d::a6]:60578 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:86123 On Feb 22, 2015, at 7:46 AM, Marko Rauhamaa wrote: > Cem Karan : >=20 >> On Feb 21, 2015, at 12:08 PM, Marko Rauhamaa = wrote: >>> Maybe the logic of the receiving object isn't prepared for the = callback >>> anymore after an intervening event. >>>=20 >>> The problem then, of course, is in the logic and not in the = callbacks. >>=20 >> 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. >=20 > 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. >=20 > 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. >=20 > 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=