[Twisted-Python] why deferred.setTimeout is not my favorite API method
glyph at divmod.com
Mon Apr 19 14:47:33 EDT 2004
On Apr 17, 2004, at 8:25 PM, Andrew Bennetts wrote:
> Ok, how about a compromise: if a creator a Deferred is able to cope
> timeouts, they should pass an "allowTimeouts=True" flag to the
> Without it, the setTimeout method will raise an AssertionError.
This is really my problem with setTimeout, really. Right now it
changes the semantics of .callback() and .errback() subtly - adding an
'allowTimeouts' flag effectively changes the object's contract at
run-time. I know that callback and errback do this already, but it's
implied that there is a single source of responsibility for calling
What we've really got here is two separate interfaces: IDeferred and
ITimeoutableDeferred. I think that it might be appropriate to
implement one as a subclass, which does the twisted.internet-related
Perhaps we're putting the responsibility in the wrong place entirely.
Deferreds which can be timed out are often tracked with some kind of ID
in a map of Deferreds. Maybe we should have a DeferredOperationManager
class which abstracts that functionality, removing the deferred from
the map when its callback/errback is called whether it's called by a
timeout or not...? Constructing a TimeoutableDeferred would then
*require* a callback that, in the common case where a
DeferredOperationManager is used, would remove the Deferred from the
mapping. Regular Deferreds would then have no setTimeout, and Bob
could use them without importing all of Twisted.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://twistedmatrix.com/pipermail/twisted-python/attachments/20040419/b1a5ec64/attachment.pgp
More information about the Twisted-Python