- A WebOb request object (just because WSGI is sort of our meme).
You could certainly grab such a thing out of the WSGI environ, but I'm not sure what that would buy you. The CP spec only requires cherrypy.request.handler to be a callable object, so the rest is up to you.
- An ability to return a WebOb Response object from the "controller" instead of a string
response (because the explicitness makes the response handling machinery a bit
simple, and for the above reason).
As long as it's iterable, that shouldn't be a problem. CP calls: "cherrypy.response.body = handler()", and the Body descriptor class only munges the output if isinstance (output, (basestring, types.FileType, None)).
However, if you're buffering output (the default), then Response.finalize will call newbody = ''.join([chunk for chunk in self.body]). It might just be easiest to wrap whatever CP outputs in a new WebOb response instance if you really need one of those.
You could certainly grab such a thing out of the WSGI environ, but I'm not sure what that would buy you. The CP spec only requires cherrypy.request.handler to be a callable object, so the rest is up to you.
- An ability to return a WebOb Response object from the "controller" instead of a string
response (because the explicitness makes the response handling machinery a bit
simple, and for the above reason).
As long as it's iterable, that shouldn't be a problem. CP calls: "cherrypy.response.body = handler()", and the Body descriptor class only munges the output if isinstance (output, (basestring, types.FileType, None)).
However, if you're buffering output (the default), then Response.finalize will call newbody = ''.join([chunk for chunk in self.body]). It might just be easiest to wrap whatever CP outputs in a new WebOb response instance if you really need one of those.