On Fri, 2011-06-03 at 02:51 -0500, Michael Merickel wrote:
> +1 to the "raise abort(..)" or "raise redirect(..)" options.
>
> I'm torn on the ability to raise arbitrary Response objects.
> Also I'm curious about what the deal is with conditional responses...
> I'm not very familiar with them but I
+1 to the "raise abort(..)" or "raise redirect(..)" options.
I'm torn on the ability to raise arbitrary Response objects.
Also I'm curious about what the deal is with conditional responses... I'm
not very familiar with them but I get curious when I hear that Pyramid can't
handle something!
Michae
On 06/02/2011 10:09 PM, Mike Orr wrote:
On Thu, Jun 2, 2011 at 12:03 PM, Wichert Akkerman wrote:
Personally I find that this coding style makes it hard to read code: you are
basically rewriting a standard language feature (raising an exception) in a
way that makes it look like a normal function
On Thu, Jun 2, 2011 at 12:03 PM, Wichert Akkerman wrote:
> On 2011-6-2 19:20, Mike Orr wrote:
>>
>> OK, but there's such a thing as view support methods, code that's
>> common to several views so it doesn't have to be repeated in all of
>> them. That's the only place where I'd use this. For insta
On 2011-6-2 19:20, Mike Orr wrote:
OK, but there's such a thing as view support methods, code that's
common to several views so it doesn't have to be repeated in all of
them. That's the only place where I'd use this. For instance:
class MyHandler(object):
def my_view(self):
params
On Wed, Jun 1, 2011 at 11:39 PM, Chris McDonough wrote:
>> #1 is important so that you can cut through multiple function calls
> if
>> you discover an error condition.
>> Use case 1: a support method/function for several handlers
>> discovers a required query parameter is missing. The applicat
On Wed, 2011-06-01 at 11:34 -0700, Mike Orr wrote:
> On Tue, May 31, 2011 at 11:21 PM, Alexandre Conrad
> wrote:
> > Hi,
> >
> > This post totally went over my head and there's a lot to read which I
> > don't feel like doing right now, so I'll just give my 2 cent straight
> > away (and if it was a
On Tue, May 31, 2011 at 11:21 PM, Alexandre Conrad
wrote:
> Hi,
>
> This post totally went over my head and there's a lot to read which I
> don't feel like doing right now, so I'll just give my 2 cent straight
> away (and if it was already addressed, reply "already addressed", and
> I will dig int
Hi,
This post totally went over my head and there's a lot to read which I
don't feel like doing right now, so I'll just give my 2 cent straight
away (and if it was already addressed, reply "already addressed", and
I will dig into the thread's archives):
2011/5/15 Chris McDonough :
> def aview(
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 wrote:
> >> I've created a branch named "httpexception-utils" on GitHub which
> >> contains an implementation of "redirect" and "abort" for Pyra
On May 31, 2011, at 12:55 PM, Chris McDonough wrote:
> On May 16, 2: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.
>
> Here's what I've
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 wrote:
> > - We will disuse the classes from webob.exc because, although they
> > advertise themselves as Response objects, they really very badly
> >
On Tue, 2011-05-31 at 14:47 -0700, Mike Orr wrote:
> On Tue, May 31, 2011 at 12:55 PM, Chris McDonough 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 rathe
On Tue, May 31, 2011 at 12:55 PM, Chris McDonough 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 ob
On May 16, 2: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.
Here's what I've decided to do with this issue:
- An exception view for the pyr
Haven't read this whole thread. I just wanted to say that although I
personally will continue to use the old style of http.exceptions, I
think this addition will help people coming from other frameworks, as
the "redirect" and "abort" keywords are commonplace for such methods
on other frameworks.
On Thu, May 26, 2011 at 6:15 AM, Daniel Holth wrote:
> 'return' makes sense because views return a response. Whether the response
> has an error code of 200, 301 or 5xx is a separate concern. Of course
> exceptions make sense too.
This only became an issue because HTTPException happens to be a WS
On 26/05/2011 14:15, Daniel Holth wrote:
In Pyramid you could replace the standard context finding methods with a
view that raises exceptions and build your whole application out of
exception views.
...which result in the PSU (That's *not* the Pyramid Secret Underground,
which doesn't exist an
'return' makes sense because views return a response. Whether the response
has an error code of 200, 301 or 5xx is a separate concern. Of course
exceptions make sense too.
In Pyramid you could replace the standard context finding methods with a
view that raises exceptions and build your whole a
On Sun, May 15, 2011 at 11:27 PM, 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 prya
Howdy!
Apologies if this post sounds too "absolutist", but I see this as an
issue that was resolved many years ago.
The way I see it there are three options:
:: Raise an exception from a pool of available exceptions.
:: Return an object, possibly an instance of something.
:: Execute a functio
On Mon, 2011-05-16 at 02:27 -0400, 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.
Thanks a lot for everybody's input on this.
There was pushback on
On 16/05/2011 19:46, Michael Merickel wrote:
I really don't like the idea of the abort(404) API providing no way to
provide a custom 404 page,
I don't think anything Chris has said suggests you wouldn't be able to
provide a customer 404 page...
that's why I mention marrying the two. And
cal
On 16/05/2011 19:42, Stephen Lacy wrote:
design. I'm not fond of thinking of things like access violations as
"exceptions".
Oh, I very much am. It's much easier and more powerful to, at any point,
raise a "whoa, you're not allowed to do that!" exception, and not have
to worry about all the i
I really don't like the idea of the abort(404) API providing no way to
provide a custom 404 page, that's why I mention marrying the two. And
calling it abort(404) in no way implies that this is different from
NotFound.
--
You received this message because you are subscribed to the Google Groups
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 tha
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 featur
On Mon, 2011-05-16 at 11:42 -0500, Michael Merickel wrote:
> Is there any support for integrating "abort(404)" with "raise
> NotFound" such that my 404 is rendered properly? Same with
> "abort(403)" and Forbidden.
No, except in the docs I explain the difference between NotFound and
HTTPNotFound an
Is there any support for integrating "abort(404)" with "raise NotFound" such
that my 404 is rendered properly? Same with "abort(403)" and Forbidden.
I'm a little torn but more in favor of the readability of using
httpexceptions directly.
--
You received this message because you are subscribed to
On 2011-5-16 08:27, 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 impo
31 matches
Mail list logo
