[Twisted-Python] Returning a deferred, maybe

[glyph at divmod.com]

On Thu, 15 Jun 2006 16:40:59 -0700, Wilfredo Sánchez Vega <wsanchez at wsanchez.net> wrote:

>   It seems like you can save the caller some grief by ensuring that  you 
>always return a deferred value (eg. by wrapping a synchronous  result with 
>defer.succeed(), as suggested in http://twistedmatrix.com/ 
>projects/core/documentation/howto/gendefer.html).  Should this be an 
>encouraged practice?

There are 2 reasons for this practice.  One is a sort of silly micro-optimization (which vanishes anyway if the caller uses maybeDeferred) and the other is an issue of convenience for the callee.  We should forget about this and just make Deferred faster.

Newer interfaces have tended toward just saying "@return a Deferred which..." rather than "@return a value or a Deferred" unless they are highly public APIs like IResource and forgetting to wrap a 2-byte string return value is a real pain.

In other words: document your interfaces precisely, and decide whose responsibility is to ensure that the value is a Deferred at some point, and you should probably prefer requiring it is a Deferred in most cases -- but I don't think that this is the sort of thing that should be in the coding standard.  It varies from situation to situation.