[py-dev] Gitting rid of "(inconsistently failed then succeeded)" ?

[Laura Creighton]

In a message of Tue, 28 Apr 2009 12:14:54 +0200, holger krekel writes:
>i agree, the error message is slightly mysterious. what about this: 
>
>    def test_inconsistent():
>        def f(l=[1,0]):
>            return l.pop()
>>       assert f()
>E       AssertionError: (assert failed but re-evaluating the
>assert expression for printing intermediate values lead to a
>True value. advise: avoid side-effects in assert expressions
>or use --nomagic)
>
>It's a bit longish but i doubt people encountering the problem
>would know where to lookup things in the documentation.
>Any other suggestion for the error message? 
>
>cheers,
>
>holger

I think that if you are going to be that long, then you might as well
be a bit longer.  I also think that the word you were looking for was
'advice', which rhymes with mice, and is a noun, and not 'advise'
which rhymes with 'surprise' and is a verb, which means to give
somebody advice.  I like 'suggest' better, but maybe that is just me.

When I've run into this before it is in the context of doing TDD with
children.  They don't know what a side effect is, and I don't think
that your error message explains that there is a real problem with the
way that they wrote the assert in the first place.  At any rate, the
puzzling thing around here was that it passed in the second case,
not that it failed the first time around, but it left students with
the idea that maybe their code was correct, when it wasn't.

I also think that it is more natural to talk about asserts failing and
then passing, or being false and then true, rather than failing and
then becoming true.

So here's my  attempt at an error message:

E: AssertionError: Evaluating the assert has undesirable side-effects.
The assert fails when the test is first run, but when subsequently
re-evaluated for printing intermediate values, it passes.  Suggest:
rewriting the assert expression in a way that avoids side-effects, or
use --nomagic)

Laura