On Thu, Sep 16, 2010 at 13:32, Armin Ronacher <armin.ronac...@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 _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com