Sorry, my last response got sent too soo.
On Tue, 2011-05-31 at 14:47 -0700, Mike Orr wrote:
> On Tue, May 31, 2011 at 12:55 PM, Chris McDonough <chr...@plope.com> wrote:
> > - 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.
>
> Aren't all Response objects WSGI applications? I thought that was part
> of the API, that they could serialize themselves.
Pyramid only requires that objects used as responses have three
attributes: app_iter, headerlist, status. They do not have to inherit
from Response or any other base class.
> > - "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.
>
> Can't anything be raised regardless of whether it inherits from
> Exception? (And for new-style classes, if the Python version is recent
> enough.)
Nope.
[chrism@thinko droidbuild]$ python2.6
Python 2.6.5 (r265:79063, Apr 29 2010, 00:31:32)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> raise object
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: exceptions must be old-style classes or derived from BaseException,
not type
> I think Pylons' abort() raises HTTPException subclasses,
> doesn't it?
Probably.
>
> So I don't see how these new exception classes will be different from
> the old ones except for a new parent and interface, which doesn't
> really affect the user.
The things mentioned above (and in the original email) conspire to make it
necessary to replace them.
It's no great loss to need to replace them, to be honest.
> > After the above steps are taken, "raise
> > pyramid.response.HTTPUnauthorized(...)" from within view code (or
> > event handler code) will generate a 401 response code with a default
> > body out-of-the-box. It will mean (probably more controversially)
> > "raise Response('OK')" will generate a 200 response code with the body
> > "OK".
>
> It may be an unorthodox way to return but it's probably better to just
> allow it than to take steps to prevent it. I could see how it could be
> a "feature" in a few cases. And again, Python doesn't seem to be
> overly concerned with what you raise. The move against string
> exceptions was to make sure you provided the actual class in the
> 'except' clause rather than comparing by equality.
--
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.
