On Tue, 2011-05-31 at 16:44 -0700, Philip Jenvey wrote: > On May 31, 2011, at 12:55 PM, Chris McDonough wrote: > > > On May 16, 2:27 am, Chris McDonough <chr...@plope.com> wrote: > >> I've created a branch named "httpexception-utils" on GitHub which > >> contains an implementation of "redirect" and "abort" for Pyramid that > >> act like their Pylons brethren. > > > > Here's what I've decided to do with this issue: > > > > - An exception view for the pyramid.interfaces.IExceptionResponse > > interface will be registed by default. This exception view will > > simply return the response object it receives as an exception. > > It will be possible to disuse this default by passing a None value > > to a constructor parameter. It will be possible to override the > > default by passing a different view callable to the same constructor > > parameter. > > > > - All objects that inherit from pyramid.response.Response (inlcuding > > instances of the Response class itself) will provide the > > IExceptionResponse interface. > > > > - We will disuse the classes from webob.exc because, although they > > advertise themselves as Response objects, they really very badly > > want to be used as WSGI applications rather than "plain response" > > objects. We will create a mirror of the http exception hierarchy > > in pyramid.response. It will be backwards compatible with the > > current > > crop of classes that are in "webob.exc" (aka > > "pyramid.httpexceptions"). > > A backwards compatibility shim for "pyramid.httpexceptions" will be > > left > > in place. > > I don't see why that's enough of a reason to throw the webob.exc exceptions > away, why's the WSGI app compatibility such a problem?
webob.exc HTTP* classes use templates that expect to have the request environ available to resolve (non-optional) values. For example, HTTPMethodNotAllowed wants to get request.environ['REQUEST_METHOD'] (to be able to show "Request method GET is not allowed" as opposed to "Request method is not allowed"). Currently, people can return to Pyramid a Response object that has no reference to the originating request. If we want to use webob.exc responses (as opposed to creating our own), users will have to return responses with enough info to resolve these sorts of values. In order to do that, we'd have to do one of the following: - Make people pass the request into the response's constructor. - Change the contract of what Pyramid considers a "valid response" (aka pyramid.interfaces.IResponse to) obligate it to include a method that effectively turns it into a WSGI application. I'm not real keen on the former because it's too much of a pain in the ass. I'm not real keen on the latter because requiring it will be a backwards compatibility foul and not requiring it will require the router to always do a guessy duck-check on every response rendering. But of the two, the latter is less onerous. > > - "pyramid.response.Response" will now be a *subclass* of > > webob.response.Response (rather than an alias) which will > > both inherit from Exception (so it can be raised) and will provide > > the pyramid.interfaces.IExceptionResponse interface. > > Is there a way to make the IExceptionResponse hook without making Response > become a subclass of Exception? That's not really the problem. The problem is Python disallowing the raising of new-style classes that don't inherit from BaseException as exception objects. Unless a Response inherits from BaseException, nobody will be able to raise one. - C -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
