[Twisted-Python] Returning a deferred, maybe

[glyph at divmod.com]

On Thu, 15 Jun 2006 19:24:20 -0700, Wilfredo Sánchez Vega <wsanchez at wsanchez.net> wrote:
>   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).

In the case of, for example, web1's IResource, callers are in framework code and callees are in application code.  Which means maybe two-dozen callers and like a billion callees.

In the case of the *new* IResource, this might not be the right factoring since you are really supposed to subclass stuff and not implement directly; and in any event, in the long term hopefully most people will be using nevow+web2 and avoiding touching the resource model directly.

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

Which reminds me.  Somebody really *should* be trying to get that C deferred stuff James did into Twisted proper; one Deferred for every locateChild sounds excruciatingly expensive for long URLs, as the code currently stands.