cascading python executions only if return code is 0

Roy Smith roy at
Mon Dec 23 16:10:50 CET 2013

In article <mailman.4553.1387804133.18130.python-list at>,
 Ethan Furman <ethan at> wrote:

> On 12/22/2013 08:57 PM, Roy Smith wrote:
> > In article <52b7a0e4$0$29994$c3e8da3$5496439d at>,
> >   Steven D'Aprano <steve+comp.lang.python at> wrote:
> >
> >> Anyway, I may be completely misinterpreting what I'm reading. Perhaps the
> >> assertion is checking a function invariant ("one of the strategies will
> >> always succeed") in which case you're doing it exactly right and I should
> >> shut up now :-)
> >
> > Yes :-)
> >
> > More specifically, the assertion exception will get caught way up in
> > some django middleware which will log a stack trace and return a HTTP
> > 50-something.  This will typically be followed by somebody like me
> > noticing the stack dump and trying to figure out WTF happened.
> This is completely misusing what assertions are for.  I hope this bit of 
> middleware (or django itself) is very clear 
> about never running with assertions turned off.

Sigh.  Sometimes I'm not sure which is worse.  The anti-assertion 
zealotry on this list, or the anti-regex zealotry.

The use of an assertion here is perfectly reasonable.  It is a statement 
that "this can never happen".

The bit of middleware I was talking about catches ALL uncaught 
exceptions.  We design our code so that all exceptions are supposed to 
get caught and handled at some appropriate place in application code.  
Nothing is ever supposed to leak up to the point where that middleware 
catches it, and anything caught there is evidence of a bug.  This is a 
common pattern in any kind of long-lived server.

And, if we didn't have the piece of middleware, the assertion (or any 
other uncaught exception) would get caught at some deeper level inside 
the django core.  The result would still be a 500 HTTP response, but 
without the added diagnostic logging we do, so it would be a lot harder 
to understand what happened.

And, if django didn't have that "except Exception" block wrapping 
everything, the gunicorn process would exit and upstart would catch that 
and restart it.

And, yes, I know that assertions get turned off with -O (frankly, I 
think that's a design flaw).  We don't run with -O.

More information about the Python-list mailing list