[Twisted-Python] Arms Crisis
![](https://secure.gravatar.com/avatar/e1554622707bedd9202884900430b838.jpg?s=120&d=mm&r=g)
Anyone who has programmed in depth with Twisted probably know about arm()ing deferreds by now. Nobody has complained as loudly as I thought they would, so I'm not sure if this is really that big of a problem, but I'm questioning my original design decisions regarding .arm(). Originally, I wanted it to be easily determineable whether your callback would be called before your stack had been escaped; so the system you returned your Deferred to would .arm() it afterwards. However, this creates lots of weird, confusing corners for callbacks to get lost in, and I have yet to see a situation where it actually matters whether your current stack frame is escaped before the callback happens. I would like to propose that we create an experimental mode where .arm() be made to do nothing (for backwards compatibility), and that .callback() call whatever callbacks are available immediately; and .addCallbacks() (and friends) will immediately call any pending callbacks. If after an extended period of testing it is discovered that there are no bugs created with this approach, we should remove .arm() entirely. I'd like some feedback on this, though. Does anyone else think that callbacks sometimes happening and sometimes not when .addCallbacks() is called makes a difference? Anyone feel strongly that .arm() is confusing and unnecessary? -- | <`'> | Glyph Lefkowitz: Travelling Sorcerer | | < _/ > | Lead Developer, the Twisted project | | < ___/ > | http://www.twistedmatrix.com |
![](https://secure.gravatar.com/avatar/f2bb7225b5047991e87a44acf37e8373.jpg?s=120&d=mm&r=g)
On 7 May 2002 at 1:31, Glyph Lefkowitz wrote:
I must have missed this message, or not cared before. I think getting rid of .arm() is a great idea. I've had a lot of problems where I forgot to arm a callback, which caused strange problems with my OSCAR code. Is this still on the table (since it has been a month)? -- Paul Swartz (o_ http://twistedmatrix.com/users/z3p.twistd/ //\ z3p@twistedmatrix.com V_/_ AIM: Z3Penguin
![](https://secure.gravatar.com/avatar/433365de0f787faa3ed3e6dd1da5884f.jpg?s=120&d=mm&r=g)
Paul Swartz wrote:
MM, wouldn't it changes the way thing work? d = Deferred().callback(1) d.addCallback(f) d.addCallback(g) d.arm() is not the same as what the new version would do: d = Deferred().callback(1) d.arm() # for emulating behaviour in current system d.addCallback(f) d.addCallback(g) No? In new system, would g() get result of f()?
![](https://secure.gravatar.com/avatar/f2bb7225b5047991e87a44acf37e8373.jpg?s=120&d=mm&r=g)
On 7 May 2002 at 1:31, Glyph Lefkowitz wrote:
I must have missed this message, or not cared before. I think getting rid of .arm() is a great idea. I've had a lot of problems where I forgot to arm a callback, which caused strange problems with my OSCAR code. Is this still on the table (since it has been a month)? -- Paul Swartz (o_ http://twistedmatrix.com/users/z3p.twistd/ //\ z3p@twistedmatrix.com V_/_ AIM: Z3Penguin
![](https://secure.gravatar.com/avatar/433365de0f787faa3ed3e6dd1da5884f.jpg?s=120&d=mm&r=g)
Paul Swartz wrote:
MM, wouldn't it changes the way thing work? d = Deferred().callback(1) d.addCallback(f) d.addCallback(g) d.arm() is not the same as what the new version would do: d = Deferred().callback(1) d.arm() # for emulating behaviour in current system d.addCallback(f) d.addCallback(g) No? In new system, would g() get result of f()?
participants (4)
-
Andrew Bennetts
-
Glyph Lefkowitz
-
Itamar Shtull-Trauring
-
Paul Swartz