[Twisted-Python] Re: Resource.render() returning NOT_DONE_YET

[Bob Ippolito]

On Monday, Apr 28, 2003, at 15:57 America/New_York, Glyph Lefkowitz 
wrote:
>> |   2.  Alternatively, allow a Deferred to be a return
>> |       value.  Then the underlying caller can add
>> |       result.finish() to the deferred chain.   This
>> |       has the advantage of not requiring finish() to
>> |       really be managed.   Either the return value is
>> |       a string, a Deferred, (or for backwards compatibiliy
>> |       NOT_DONE_YET).  In either of the primary cases,
>> |       result.finish() always gets called... thus making
>> |       it easier on newbies.
>
> I've discussed this with several different people at various times... 
> the trouble is, there isn't really a use-case that Deferreds make 
> easier.  render() ends up being a relatively low-level interface, and 
> the NOT_DONE_YET/write/finish API is quite convenient for the stuff 
> that has been implemented with it.
>
> I am definitely a True Believer in the Deferred, but in this case it 
> just doesn't seem worth the inconvenience of deprecating things and 
> shuffling stuff around for a vanishingly small benefit.

The error handling inherent with Deferred makes it worth it IMHO.  I 
see a lot of NOT_DONE_YET responses fail and it just hangs for the web 
user unless the developer of the function did a lot more work.. a 
deferred could just errback on a failure rather than having to summon 
the web traceback mechanism manually.

-bob