[Twisted-Python] Arms Crisis

Glyph Lefkowitz glyph at twistedmatrix.com
Tue May 7 02:31:18 EDT 2002


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      |




More information about the Twisted-Python mailing list