[Twisted-Python] Returning a deferred, maybe

[Wilfredo Sánchez Vega]

   I guess I'm not seeing any justification for returning a deferred  
some of the time other than:

	- the micro-optimization (which your saying is silly) and

	- convenience for the callee (but wrapping a result in defer.succeed 
() is hardly a burden, and you are basically just passed the  
inconvenience down to every caller, which is usually a bad allocation  
of convenience-ness-es).

   The reason I thought it a good idea to require always returning a  
deferred is that I had a lot of code which depended on locateChild()  
to return a non-deferred value, which is clearly broken.  But none of  
the unit tests caught this, because I've never traversed a resource  
which returned a deferred in locateChild().  dreid pointed this out  
to me, so I changed some routines to fix this and had them always  
return a deferred, and sure enough, I ended up having to fix a *lot*  
of code.

   The point being that callers of functions that _usually_ return  
non-deferred values will usually work, enough so that it's hard to  
catch them with unit tests unless you go out of your way to ensure  
that deferreds are tested, which is unlikely if you also wrote the  
offending code.

	-wsv


On Jun 15, 2006, at 5:14 PM, glyph at divmod.com wrote:

> 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.
>
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python