cascading python executions only if return code is 0

Ethan Furman ethan at
Mon Dec 23 17:00:12 CET 2013

On 12/23/2013 07:10 AM, Roy Smith wrote:
> 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.

I am not a zealot (I'm not!  Really!! ;) .  I just find it alarming to have major pieces of software rely on a feature 
that can be so easily tuned out, and it wasn't clear from your comment that it was /any/ exception.

Mostly I don't want newbies thinking "Hey!  I can use assertions for all my confidence testing!"

Just as one data point OpenERP, which has a lot of good features, unfortunately uses assert to test user input.  :(


More information about the Python-list mailing list