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
Why not just cut to the chase and call them "examples".
They can then be fully fledged working applications, and users can be
advised to copy them to their own directory structures before continuing.
That's probably what everybody does anyway, right?
Steve
On Mon, Mar 21, 2011 at 12:06 PM, Mark
Since mod_wsgi uses long-lived processes, I've decided to keep the
connection open for the life of the process (and auto-reconnect if there's a
failure).
I'm actually a little surprised that people here are connecting &
disconnecting with each request, as it feels unnecessary. Is there some
disad
Yeah, implicitly breaking HEAD sucks. :)
Implicitly allowing POST data into GET requests also sucks. :)
Steve
On Mon, Mar 14, 2011 at 12:37 PM, Reed L O'Brien wrote:
> On Mar 14, 2011, at 3:13 PM, Stephen Lacy wrote:
>
> >
> >
> > On Fri, Mar 11, 2011
Just my quick 2c:
YAML vs. INI? Just use Python.
Why depend on another component and parser (think: user debugging of
configuration errors with mis-typed config files).
Why fuss over "how does this support lists" and other similar issues?
And, for me, the most important issue is that when I se
On Fri, Mar 11, 2011 at 6:16 AM, Graham Dumpleton <
graham.dumple...@gmail.com> wrote:
>
>
> On Thursday, March 10, 2011 1:44:17 PM UTC-5, Steve Lacy wrote:
>>
>> What's the recommended way to get proper HEAD request support using
>> pyramid + mod_wsgi?
>>
>> Right now, with my "vanilla" mod_wsgi
To me, the answer to this question really lies in "what session
implementation are you using?"
For me, I've opted to use a session in a database on the server, which
allows me to set arbitrarily large items into the session without any real
penalty.
Then, for whatever you'd set a custom cookie fo
Steve
On Thu, Mar 10, 2011 at 11:12 AM, Reed L O'Brien wrote:
> On Mar 10, 2011, at 1:44 PM, Stephen Lacy wrote:
>
> > What's the recommended way to get proper HEAD request support using
> pyramid + mod_wsgi?
> >
> > Right now, with my "vanill
What's the recommended way to get proper HEAD request support using pyramid
+ mod_wsgi?
Right now, with my "vanilla" mod_wsgi configs, and request_method='GET' on
my view_config decorators, my HEAD requests are 404'ing. I tried setting
request_method=['GET', 'HEAD'] but it seems as this syntax i
Whoops, that second link was broken. Here's the right link:
http://github.com/slacy/minimongo
Steve
On Wed, Mar 9, 2011 at 11:44 AM, Stephen Lacy wrote:
> Here's my entire custom sessions implementation:
>
> https://gist.github.com/862824
>
> I'm using my own
b.com/862824>Steve
On Wed, Mar 9, 2011 at 11:24 AM, Stephen Lacy wrote:
> CSRF protection is a fairly complex topic, and Pyramid's brief textual
> description in the docs above really glosses over many of the important
> aspects of how to handle CSRF protection.
>
> In m
CSRF protection is a fairly complex topic, and Pyramid's brief textual
description in the docs above really glosses over many of the important
aspects of how to handle CSRF protection.
In my form handling view, I'm using code that looks like this:
if not request.session.csrf_valid(request.POS
lso
> > important to note that if Pyramid itself becomes obsolete in 5-10
> > years, as Pylons did, then at least you can carry over your knowledge
> > of SQLAlchemy, paster, deform, etc. to the next framework.
> > Essentially what I giving a world world example of th
Okay, chiming in here. :) Yeah, this is my post. I've been pretty quiet
here.
Sorry for the somewhat negative tone, as you can imagine, the post was
written after spending several hours digging through a very large amount of
the Pyramid source code trying to figure out the answer to what seemed
14 matches
Mail list logo