[Twisted-Python] why deferred.setTimeout is not my favorite API method

[Glyph Lefkowitz]

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 
> with
> timeouts, they should pass an "allowTimeouts=True" flag to the 
> constructor.
> Without it, the setTimeout method will raise an AssertionError.

Gross.

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 
those methods.

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 
stuff.

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...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://twistedmatrix.com/pipermail/twisted-python/attachments/20040419/b1a5ec64/attachment.pgp