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

[Bob Ippolito]

On Apr 17, 2004, at 6:22 PM, Jonathan Simms wrote:

> This is response to issue 178 on the twisted tracker:
> http://www.twistedmatrix.com/users/roundup.twistd/twisted/issue178,
> about the deferred method setTimeout.
>
> The reason why I added a "DON'T USE THIS" to the docstring was that I
> find that we are telling people this at least once a week. I think it
> has more gravitas coming from the API documentation, as there is this
> illusion that the people on IRC don't really know what they're talking
> about, but if the author has marked something in the documentation, it
> has a certain level of legitimacy.
>
> I agree with spiv in the sense that it would be nice to have a minimal
> interface that would provide this functionality. However, i think that
> the level of control that is needed to pull this off properly is best
> served by writing an explicit timeout method and accompanying call to
> callLater.
>
> now, I'd like to present the idiom that we are try to encourage users 
> to
> follow every time we have to steer them away from setTimeout.

+10, setTimeout as-is is just about the absolute worst way it could 
possibly be implemented, and this version makes sense.  The only 
"problem" is that existing APIs will have to be refactored such that 
there is something useful and public you can use for 
"handleTimeoutCondition", because IIRC most of them don't have a 
cancellation feature at all -- let alone one that's public and usable.

-bob