This whole discussion (and current implementation of returns or raises for httpexceptions) seems to violate the Zen of Python: "There should be one-- and preferably only one --obvious way to do it."
Chris, what's the root issue that made you think that "return abort(401)" would be a better API than "return HTTPUnauthorized(...)"? What specific problem are you trying to solve? Is it just Pylons compatibility? How about making a utils or library specifically for that task, and making it really clear that there's a "Pyramid way" and a "Pylons compatibility way"? (Again, this violates the Zen, but at least it's a bit more explicit) In general, I find the "returns or raises" pattern to be a fairly weird design. I'm not fond of thinking of things like access violations as "exceptions". I think of those as normal parts of my application. Things like "divide by zero" are exceptions. :) I'd like to be able to read my view function and know exactly what HTTP return codes are going to be produced. When some function way down the call stack can raise up an arbitrary exception from httpexceptions, it makes it really unclear what my view is going to actually do. Steve On Mon, May 16, 2011 at 11:20 AM, Chris Withers <ch...@simplistix.co.uk>wrote: > On 16/05/2011 18:58, Tres Seaver wrote: > >> On 05/16/2011 02:27 AM, Chris McDonough 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. >>> >>> In short, the abort feature is used like this: >>> >>> from pryamid.httpexceptions import abort >>> >>> def aview(request): >>> abort(401) >>> >>> This will perform the same job as what used to be necessary as: >>> >>> def aview(request): >>> return HTTPUnauthorized() >>> >> > I'd be +1 on making there be one object that could be returned or raised > for each of NotFound, Forbidden, etc, but I guess I'm unaware of the holy > way that would need to be waged. > > I'm 0 on the short-form functions above that raise or return these (I > believe the code above has a bug - should the return be a raise in the > definition of aview?) > > > View code would look like:: >> >> @returnRaised >> def aview(request): >> abort(401) >> > > I'm a big -1 on this though. Less decorators the better... > "Why do I have to decorate something just to get what should be default > behaviour?" > "I have to decorate every single one of my view methods?!" > Not my specific views, but I can see many people having them... > > Chris > > -- > Simplistix - Content Management, Batch Processing & Python Consulting > - http://www.simplistix.co.uk > > > -- > 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. > > -- 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.
