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

[Glyph Lefkowitz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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):
         if self.authenticated:
             return self.goodies

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)

iD8DBQE+rYejvVGR4uSOE2wRAnNVAJ9yv7vhkmlVSYT/Ba5HhGF9UmXaGwCghHEa
Il76B0P3doYwTxldfvakhms=
=as/e
-----END PGP SIGNATURE-----