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 |