[Twisted-Python] Re: Resource.render() returning NOT_DONE_YET
glyph at twistedmatrix.com
Mon Apr 28 15:57:15 EDT 2003
-----BEGIN PGP SIGNED MESSAGE-----
On Monday, April 28, 2003, at 11:17 AM, Clark C. Evans wrote:
> On Mon, Apr 28, 2003 at 04:09:35PM +0000, Clark C. Evans wrote:
> | I was just giving a quick Twisted tutorial to someone using
> | twisted and as we were breaking page construction into more
> | than one chunk... an unexpected stumbling block occurred --
> | returning NOT_DONE_YET form the resource's render() function.
> | I was thinking about two other options:
> | 1. Perhaps NOT_DONE_YET could just be None, this
> | way, it can be the default return value. As I'm
> | browsing through my code this is the most common
> | return... why not make it the default.
The reasoning behind not allowing None as a default value is that
forgetting is too easy. If you're writing a simple request that has a
render() method that looks like
def render(self, request):
the default behavior should not be "hang forever".
> Err, this isn't exactly what I was thinking. What
> I was proposing... if during the scope of the render()
> function, req.write() is called, then a None value
> would be an allowable return. And if None is returned,
> req.finish() would be called automagically.
What if you wanted to start writing the page in the render() method but
keep writing it later? Then we have None as a synonym for NOT_DONE_YET
except in certain situations where you've done something to the request?
> | 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)
-----END PGP SIGNATURE-----
More information about the Twisted-Python