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