[Web-SIG] PEP 444 (aka Web3)

[Dirkjan Ochtman]

On Thu, Sep 16, 2010 at 13:32, Armin Ronacher
<armin.ronacher at active-4.com> wrote:
> The motivation is that you can pass that to constructors of response objects
> already in place.
>
> response_tuple = response.get_response_tuple()
> response = Response(*response_tuple)
>
> The order "body", "status code", "headers" is what Werkzeug and WebOb are
> currently using.  Django has (content, mimetype, status) as constructor but
> if they detect a list/dict on the third parameter they could assume that
> mimetype referes to the status thus they have a proper upgrade path.

Okay, I can see why the order makes sense from a default arguments
point of view, but I'm still not sure why it helps if the Response()
signature looks like the application return signature.

> That would be a nice to have, but makes the middleware logic harder because
> each middleware would have to check for the type.
>
> Works for 2.x, but on 3.x that would mean each middleware would have to
> check the type before each operation and convert to bytes if necessary which
> means a lot of overhead for each middleware in the stack.

Okay, I guess it makes sense. I just thoroughly dislike that we're
making applications harder in a bunch of places to make the life of
middleware easier. Surely we write more applications than middleware?
Can we somehow invert the model to have the gateway act as a
controller for middleware, so that we can canonicalize application
returns before passing them to the middleware? Or provide a function
in wsgiref that allows me to write an application like this:

import wsgiref

def app(environ):
     return wsgiref.canonicalize(200, {'Content-Type': 'text/plain'}, ['foo'])

Maybe it should be an exceedingly light-weight response class (which
could be inherited by the frameworks) instead.

Cheers,

Dirkjan