Ascription is an Anathema to any Enthusiasm

I’ve been looking at Python’s Twisted.   It’s a framework for writing event driven system.  I have built far too many event drive frameworks in my day.

One of the core abstractions in Twisted is an object they call a “Deferred.”  I really wish they had called it a Promise.  Routines that need time to gather their results immediately return an instance of Deferred and then latter they give that instance a kick to signal how it came out.  For example here’s an imaginary bit of code.  Remind_me returns a deferred that presumably will get a kick next tuesday.

pending_reminder = reminded_me("next tuesday") 


Back in the 1960s I learned a language called SNOBOL, a precursor awk, Perl, icon, and the amazing SL5. One of SNOBOL’s amusing features was that you were encouraged to write, for every statement, a clause to handle both success and failure. Which is helpful if mostly your doing pattern matching.

Back in the 1960s I learned a language called SNOBOL, a precursor awk, Perl, icon, and the amazing SL5.  One of SNOBOL’s amusing features was that you were encouraged to write, for every statement, a clause to handle both success and failure.  Which is helpful if mostly your doing pattern matching.

These days every time you call a function you know that it can either work out, or it can throw and exception.  It’s the same idea. The methodical Twisted programer has to worry like a SNOBOL programmer.  But unlike SNOBOL your forced to bundle up everything in functions (Python’s lambda expressions are quite limited).

pending_reminder.callback(pay_the_bills)
pending_reminder.errback(reschedule_the_bill_payments)

These Deferred instances are, in effect, a pipe from the process working on getting your result and the party that requested for that result. The Deferred is effectively a contract between these two parties; call the two parties the buyer and the seller.  In the above example they buyer purchased wake up call next tuesday and the seller has promised to either deliver that wake up, or to at least signal an error.

What Twisted is doing is all well and good, but I was a bit disconcerted that there no well blocked out protocol for the buyer update the seller.  Say, for example, I’m building a complex display for the user.  I ask a number of parties to go gin up bits of that display and them give me their promise to get right back to me.  Meanwhile the user loses interest and closes the window.  I haven’t any way to notify the providers that they can tear down their efforts on my behalf.  Given the ADD of modern users that’s not an exceptional case.

That example is really just a special case of the general problem of flow control.  In many systems I’ve built the quality of the communication channel varies by orders of magnitude depending on where the user is sitting.  It is nice to be able to tell the downstream provider what frequency he should be updating at.  The same problem arises when the user’s client goes to sleep.

No doubt these problems can be layered in on top of Twisted’s abstractions, but as I said I found it discomforting that these is now way for the buyer say ‘never mind’ to the seller.